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STORING SYSTEM-LEVEL MASS STORAGE 
CONFIGURATION DATA IN NON-VOLATILE 

MEMORY ON EACH MASS STORAGE 
DEVICE TO ALLOW FOR REBOOT/POWER- 
ON RECONFIGURATION OF ALL s 
INSTALLED MASS STORAGE DEVICES TO 
THE SAME CONFIGURATION AS LAST USE 

FIELD OF THE INVENTION 

The present invention relates generally to an arrangement 10 
for and method of operating a computer system including a 
host computer having system Random Access Memory 
(RAM) and using a Basic Input/Output System (BIOS) to 
operate the host computer. More particularly the arrange- ^ 
ment and method of the invention stores at least a portion of 
the BIOS used to operate the system within the mass 
memory storage of a mass memory storage peripheral com- 
puter device rather than in Read Only Memory (ROM). The 
BIOS stored in the mass storage media may be expansion 
BIOS associated with a particular peripheral computer 
device and/or system BIOS associated with the host com- 
puter. The ROM refers to either system ROM provided by 
the host computer or peripheral ROM provided by a periph- 
eral device (either on a card or on the device itself). ^ 

BACKGROUND OF THE INVENTION 

The computer industry is continuously evolving, provid- 
ing faster processors, larger memory capacities, and a vari- 
ety of peripheral devices which may be interconnected with 30 
a host computer. Due to these increasing speeds and 
capacities, one of the developments in the industry is a 
peripheral bus implementation known as Peripheral Com- 
ponents Interface (PCI). This peripheral bus has been devel- 
oped to provide an expansion mechanism between the host 35 
computer and peripheral computer devices or expansion 
boards. 

The PCI peripheral bus is designed to be both processor 
and computer system architecture independent with the PCI 
electrical, protocol, and hardware interface requirements 40 
remaining the same regardless of the CPU or host system 
computer architecture being used. This allows the same 
peripheral computer device to be connected to a variety of 
different host systems without requiring different versions of 
the device for each type of host system with which the 45 
device is intended to be used. Because the PCI bus is 
independent of the processor and the computer architecture, 
each host system is required to provide a mechanism to map 
host I/O and memory space to the addressing mechanism 
used on the PCI bus. This is also true of the expansion ROM 50 
memory space of a peripheral computer device, which 
typically includes initializing information and operating 
information such as code and data for that peripheral com- 
puter device. Therefore, relocatable expansion ROM loca- 
tion addresses are allowed on a PCI device. This is not the 55 
case for earlier bus architectures such as the Industry Stan- 
dard Architecture (ISA) Bus. 

As shown in FIG. 1, which illustrates one example of a 
typical PCI-based computer system designated by reference 
numeral 10, system 10 includes a host computer 12 having 60 
a system BIOS 13 for operating host computer 12 and 
having system RAM memory 14 associate with host com- 
puter 12. System BIOS 13 is stored in system ROM 15 
within host computer 12. A PCI peripheral bus 16 is con- 
nected to host computer 12 and system RAM 14 using a host 65 
bridge 17. The system also includes a peripheral computer 
device 18, for example a hard disk drive, which is connected 
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to the PCI bus such that the host computer may communi- 
cate with the peripheral computer device using the PCI bus. 
Device 18 includes ROM 20 which contains any expansion 
BIOS 22 required in the host system in order to initialize 
and/or operate peripheral computer device 18. In a system 
using the PCI bus, the host system BIOS and/or operating 
system must provide a configuration manager that recog- 
nizes individual PCI devices, allocates resources, and 
enables those devices. It is the responsibility of the configu- 
ration manager to copy any expansion BIOS of the periph- 
eral device into the host computer's RAM and then execute 
any initialization routine provided within the expansion 
BIOS to provide proper peripheral device initialization. 

Referring to FIG. 2 A, which diagram matically illustrates 
the expansion BIOS 22 contained in ROM 20, the PCI 
specification allows for multiple code images, for example 
24a-24d, to be stored within the expansion BIOS 22 with 
each code image providing the appropriate information for 
a particular computer architecture. In this example, code 
image 24a might correspond to an Intel® based system, 
code image 24b might correspond to a Power PC® based 
system, and so on. These multiple code images 24a-24d 
increase the amount of information which is included in the 
expansion BIOS thereby increasing the amount of ROM 
required to store the expansion BIOS 22. As shown in FIG. 
2B, code image 24a, and each of the other images, includes 
a header region 26, Depending on the requirements of device 
18 to which the expansion BIOS 22 corresponds, each image 
may also include a data structure region 28, runtime code 30, 
initialization code 32, and a check sum 34, Referring to FIG. 
2C, the PCI specification also requires that each PCI device 
includes a configuration space memory 35 which is 256 
bytes in size and which conforms to the PCI format illus- 
trated. The information provided by configuration space 35 
includes a device ID register 36 containing the device 
identification and a configuration register 38 containing a 
requested amount of memory space. The configuration reg- 
ister 38 specifies the amount of memory space required 
within the host computer memory to map the expansion 
BIOS 22 associated with peripheral computer device 18. 

As will be described in more detail immediately 
hereinafter, once expansion BIOS 22 has been copied into 
host system RAM 14, the initialization code 32 from the 
proper code image, for example code image 24a, is run. This 
initializes device 18 and provides the proper hooks into the 
system for operating device 18 using runtime code 30 from 
the proper code image, in this case, image 24a t as contrasted 
with image 24b, c, or d. Once the initialization code has been 
run, control is returned to the host system and only the code 
required for operating device 18 is left in host system RAM 
14 where it remains throughout the operation of the system. 
The excess information of the proper code image 24a being 
only necessary for initialization of device 18 is no longer 
necessary. Therefore, the memory used to store this excess 
information is made available to be used again by host 
computer 12, thereby reducing the usage of RAM 14 to store 
the necessary portions of expansion BIOS 22. 

Referring now to FIG. 3, a typical sequence for obtaining 
expansion BIOS from a PCI peripheral device and storing it 
within, system RAM will be described in detail using the 
example of system 10 described above. After computer 
system 10 is turned on, indicated in block 40 of FIG. 3, the 
processor of host computer 12 starts running system code 
typically called Power-On-Self-Test (POST) as indicated by 
block 42. The POST code performs unrelated system con- 
figurations (block 44) and then starts the configuration of the 
PCI bus add-on peripheral devices by checking for the 
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presence of peripheral devices, such as peripheral device 18, store the expansion BIOS remaining in system RAM after 

as indicated by decision box 46. Once the POST code finds initialization code 32 has run as read only. And finally, at this 

peripheral device 18 and as respectively indicated in blocks point the sequence returns to decision block 56 to see if there 

48, 50, and 52 of FIG. 3, the POST code starts the configu- are any more devices present to be configured, 

ration of device 18, allocates host I/O and RAM memory 5 As described above, the expansion BIOS 22 is typically 

space as requested by device 18, and configures interrupt stored in ROM 20 located on the peripheral computer device 

and allocates IRQs on host computer 12 as requested by or an expansion card. However, this approach has the 

device 18. At this point, the POST code determines if device disadvantage of adding to the cost of the device by adding 

18 has an expansion BIOS that needs to be loaded and the cost of ROM 20 which in a system using a PCI bus is 

configured as indicated by decision block 54. If there is no 10 only used to store the expansion BIOS for loading into the 

expansion BIOS, as indicated by clock 56, the POST code system after system start-up. More particularly, in a system 

goes on to the next peripheral device. If all the devices are using a PCI bus and as mentioned above, the host computer 

configured, the POST code goes on to boot the operating is required to copy the expansion BIOS into the host 

system as shown in block 58. If, however, there is an system's RAM. For purposes of efficiency, the system uses 

expansion BIOS to be loaded from the device, as is the case 15 the copied expansion BIOS stored in its own memory rather 

for device 18, the expansion BIOS is loaded and configured than referring back to the ROM on the device when the 

as indicated by block 60. Once this loading of the expansion expansion BIOS is required for the operation of the system. 

BIOS for device 18 is completed, the sequence proceeds to Therefore, once the necessary portions of the proper image 

block 56 and the process continues for any other devices. 24a are stored in the host system's RAM, ROM 20 is not 

Referring now to FIG. 4, the typical process of loading 20 accessed a S ain until the system is turned off and on again at 

and configuring the expansion BIOS of a peripheral device which time the proper image of the expansion BIOS is again 

as indicated in block 54 and 60 of FIG. 3 will be described loaded int0 the host system RAM. Also as mentioned above, 

in more detail. Starting at decision block 54 in which the because multiple images may be required in order to allow 

POST code determines if peripheral device 18 has an the same device to be connected to a variety of host systems 

expansion BIOS, the POST code writes to and reads from 25 havin g different computer architectures, the size of overall 

the configuration register 38 of configuration space memory expansion BIOS 22 and therefore ROM 20 required to store 

35 of peripheral device 18 to determine if an expansion the expansion BIOS can be rather large. This can cause the 

BIOS is present on the device and, if so, how much memory expansion BIOS ROM 20 to become a significant portion of 

space is requested. Once it is determined that there is an tne cost °f device 18. 

expansion BIOS, the process of loading and configuring the 30 The cost of this expansion BIOS ROM varies depending 

expansion BIOS associated with device 18 generally inch- on the specific type of ROM used. In a case in which high 

cated by block 60 of FIG. 3 proceeds as will now be volumes of the devices are being produced, the ROM may 

described in detail. be manufactured with the expansion BIOS programmed into 

As indicated by block 62 of FIG. 4, the POST code the R0M at the time of manufacture of the ROM. This 

determines an acceptable address to map expansion BIOS 22 35 approach has the advantage of being less expensive; 

stored in ROM 20 of device 18 to and writes that address to however, once this type of ROM is programmed, it may not 

the configuration register 38 of configuration space memory be changed. If the device is modified in any way which 

35 on PCI peripheral device 18. In block 64, the POST code requires a change in the expansion BIOS, or if a bug is found 

then enables expansion BIOS ROM decoding on the device. in the expansion BIOS, all of the ROM that have been 

Next, peripheral device 18 maps its ROM memory starting 40 produced with the old expansion BIOS must be scrapped, 

at the address the POST code wrote to configuration register This approach does not provide much flexibility in updating 

38 in configuration space memory 35 on device 18 as and improving the operation of the device by updating the 

indicated in block 66. The device sets up its internal address expansion BIOS. 

decoder to decode the memory address range to which the In another approach, the expansion BIOS is programmed 
ROM memory is mapped. As indicated in block 68, the 45 into the ROM after the ROM is manufactured. This allows 
POST code reads through the expansion BIOS by reading the expansion BIOS to be updated without having to scrap 
the memory locations to which the expansion BIOS was the ROM which have been manufactured as would be the 
mapped, searching for an appropriate expansion BIOS code case for the above described approach. Although the pro- 
image, in this case code image 24a of expansion BIOS 22. grammable ROM provides more flexibility, it is more expen- 
If an appropriate code image is not found, as shown in 50 sive than ROM which is programmed during its manufacture 
decision block 70, the sequence returns to block 56 to see if and further increases the cost of providing the expansion 
there are additional devices to be configured. However, if BIOS ROM. With the extremely competitive nature of the 
proper code image 24a is found, the sequence moves to computer peripheral device market, for example in the area 
block 72 in which the POST code determines a memory of hard disk drives, the ability to reduce or even eliminate 
location within host system RAM 14 to copy the expansion 55 the cost of the ROM for the expansion BIOS would provide 
BIOS code into from the device's ROM 20. The POST code a significant competitive advantage, 
then in block 74 copies the appropriate code image 24a from The present invention discloses a novel arrangement and 
the device's ROM 20 into system RAM 14. As indicated in method for operating a host computer having a system BIOS 
blocks 76 and 78, the POST code calls initialization code 32 which is used to operate the host computer and having 
of expansion BIOS 22 now in system RAM 14 and runs 60 system RAM associated with the host computer. The 
initialization code 32 further configuring peripheral device arrangement and method allow at least a portion of the BIOS 
18 and installing system level software support including to be stored within the mass memory storage of a mass 
interrupt handlers, device specific data, etc. Once initializa- memory storage peripheral device which is connected to the 
tion code 32 is finished, initialization code 32 returns control host computer. The BIOS stored within the mass memory 
of the system to the POST code as shown in block 80. In 65 storage may be expansion BIOS associated with any par- 
block 82, the POST code performs any final initialization licular peripheral computer device and/or expansion BIOS 
such as marking the portion of the system RAM 14 used to associated with the mass memory storage peripheral com- 
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puter device itself. The BIOS stored within the mass In this embodiment, the host computer may include 
memory storage may also be system BIOS associated with system ROM memory storage containing system BIOS 
the host computer. This approach significantly reduces or (system ROM). The peripheral ROM storage memory con- 
even eliminates the need for and cost of the expansion BIOS taining the first portion of the expansion BIOS may be 
ROM for the particular peripheral computer device and/or 5 separate and apart from the system ROM storage memory, 
the expansion BIOS ROM for the mass memory storage or * alternatively, the peripheral ROM storage memory con- 
peripheral computer device. This approach may also be used ^"B the fir * 1 P° rtion of the expansion BIOS may be part 
to significantly reduce the need for and cost of the system ° f ^ s y stem R0M stora S e memor y- J n th fi e case 10 wmc f n £ e 
BIOS associated with the host computer. Since some or ail storage memory containing the first portion of the 
of the expansion BIOS and/or some of the system BIOS is u ex P aQS10n BI0S ^parate and apart from the system ROM 
stored in the mass memory storage of a mass memory f lora S e j?*™? 'his Peripheral ROM storage memory con- 
storage peripheral computer device, this approach also pro- ta !T g k the first P ortlon ° f th f expansion BIOS associated 
vides substantially improved flexibility in updating and Wllh ' he particular penpheral computer device may be is 
improving the system or fixing bugs in the BIOS without located on the P art,cular P^pheral computer device, 
having to use programmable ROM. Using this novel is In another embodiment in which the method and arrange- 
approach, the majority of the system BIOS and the majority meat arc a method ™ d arrangement of operating a particular 
of, or all of, the expansion BIOS associated with the peripheral computer device, the entire expansion BIOS 
peripheral devices connected to the system may be updated associated with the particular peripheral computer device is 
by simply reloading a revised BIOS into the mass memory slorcd the mass memory storage of the mass memory 
storage of the mass memory storage device without having 20 stora S e Peripheral computer device. In this embodiment, the 
to scrap any BIOS ROM method and arrangement further include an operating 

mechanism for commencing the operation of the system,. 

SUMMARY OF THE INVENTION Once the operation of the system is commenced, the oper- 

As will be described in more detail hereinafter, an ating mechanism causes the host computer to (i) access the 

arrangement for and method of operating a computer system 25 mass memor y storage of the mass memory storage periph- 

is disclosed herein. The computer system includes a host eral computer device, (ii) obtain the expansion BIOS asso- 

computer having system RAM and a mass memory storage ciated with the particular peripheral computer device, and 

peripheral computer device such as a hard disk drive con- ("0 store within the system RAM the expansion BIOS 

nected to the host computer. The host computer uses a BIOS associated with the particular peripheral computer device, 

to control the operation of the computer system. The 30 In a specific version of the embodiment which stores the 

arrangement and method allow at least a portion of the BIOS entire expansion BIOS within the mass memory storage of 

to be stored within the mass memory storage of the mass the mass memory storage peripheral computer device, the 

memory storage peripheral computer device rather than mass memory storage peripheral computer device includes a 

requiring all of the BIOS to be stored within BIOS ROM. memory buffer on the mass memory storage peripheral 

In one embodiment, the method of and arrangement for 35 computer device. In this version, the expansion BIOS asso- 

operating the computer system is a method of and arrange- cia ted with the particular peripheral computer device 

ment for operating a particular peripheral computer device includes a first portion of the expansion BIOS and a second 

connected to the host computer using a peripheral bus in portion of the expansion BIOS. Also, the operating mecha- 

which relocatable expansion BIOS location addresses are riism causes the host computer to perform a Power-On-Self- 

allowed, such as a PCI bus. In this embodiment, the BIOS 40 Test upon the commencing of operation of the, system. The 

is expansion BIOS associated with the particular peripheral mass memory storage peripheral computer device includes a 

computer device. The operation of the peripheral computer mechanism for loading the first portion of the expansion 

device requires the host computer to obtain the expansion BIOS associated with the particular peripheral computer 

BIOS associated with the particular peripheral computer device into the memory buffer of the mass memory storage 

device and load the expansion BIOS into the system RAM. 45 peripheral computer device within the time frame of the 

This embodiment includes ROM storage memory Power-On-Self-Test. This allows the operating mechanism 

(peripheral ROM) for containing a first portion but not all of 10 access the memory buffer and obtain the first portion of 

the expansion BIOS associated with the particular peripheral expansion BIOS. Thereafter, by using the first portion of the 

computer device. A second portion of the expansion BIOS expansion BIOS, the host computer is caused to (i) access 

associated with the particular peripheral computer device is 50 th e mass memory storage of the mass memory storage 

stored within the mass memory storage of the mass memory peripheral computer device, (ii) obtain the second portion of 

storage peripheral computer device connected to the host the expansion BIOS which is associated with the particular 

computer. The particular peripheral computer device may or peripheral computer device and which is located within the 

may not be the mass memory storage peripheral computer mass memory storage of the mass memory storage penph- 

device. The arrangement further includes an operating 55 eral computer device, and (iii) store the second portion of the 

mechanism for causing the host computer to access the expansion BIOS within the system RAM. 

peripheral ROM and obtain the first portion of the expansion In each of the above described embodiments, the particu- 

BIOS associated with the particular peripheral computer lar peripheral computer device associated with the expan- 

devicc. Thereafter, by using the first portion of the expansion sion BIOS may actually be the mass memory storage 

BIOS, the host computer is caused to (i) access the mass 60 peripheral computer device which provides the mass 

memory storage of the specific mass memory storage memory storage in which at least a portion of the expansion 

peripheral computer device, (ii) obtain the second portion of BIOS is stored. Alternatively, the particular peripheral com- 

the expansion BIOS which is associated with the particular puter device may be any other peripheral computer device 

peripheral computer device and which is location within the such as a video card, a network card, or any other peripheral 

mass memory storage of the mass memory storage periph- 65 computer device or expansion card, 

eral computer device, and (iii) store the second portion of the In another embodiment, the BIOS is system BIOS asso- 

expansion BIOS within the system RAM. ciated with the host computer. In this embodiment a first 
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portion of the system BIOS is contained within a BIOS FIG. 5 is a block diagram of one embodiment of a 

ROM located within the host computer. A second portion of computer system designed in accordance with the present 

the system BIOS is stored within the mass memory storage invention which uses a peripheral bus, in which relocatable 

of the mass memory storage peripheral computer device. expansion BIOS location addresses are allowed, to connect 

This second portion of system BIOS is retrieved and stored 5 a peripheral computer device to a host computer, 

in system RAM in the same manner as the expansion BIOS FIG. 6A is a detailed diagrammatic illustration of a first 

stored within the mass memory storage as described previ- portion of an expansion BIOS in accordance with the present 

ously. invention for a peripheral computer device; 

In another aspect of the invention, a computer memory FIG. 6B is a detailed diagrammatic illustration of a second 

storage medium other than ROM for use in a computer 1° portion of an expansion BIOS in accordance with the present 

system is disclosed. The computer system includes a host invention which is associated with the first portion of the 

computer having system RAM associated with the host expansion BIOS illustrated in FIG. 6A; 

computer and a mass memory storage peripheral computer FIG. 6C is a detailed diagrammatic illustration of the 

device which is connected to the host computer. The host configuration space memory of a PCI peripheral device; 

computer uses a BIOS to control the operation of the system. 15 _ . a . ... c u 

A . , . c *u nmc • ♦ a *u- *u ~ FIG. 7 is a now chart illustrating the details of how an 

At least a portion of the BIOS is stored within the mass . „ T ^« . . & - , . , , , 

memory storage of the mass memory storage peripheral expansion BIOS as shown in FIGS. 5, 6A and 6B is loaded 

computer device for use by the host computer after the host mi0 s y stem **** of a host com P uter m accordancc ™* the 

computer has loaded the BIOS stored in the mass memory present invention, 

storage into the system RAM of the host computer. The 20 FIG. 8 is a flow chart illustrating how a portion of a 

computer memory storage medium of the invention has a system BIOS stored in a mass memory storage peripheral 

portion of the memory storage medium containing BIOS for computer device as shown in FIG. 5 is loaded into system 

controlling the operation of the host computer. In one RAM of a host computer in accordance with the present 

embodiment of the computer memory storage medium, the invention; 

medium is the mass memory storage of the mass memory 25 FIG. 9 is a block diagram of another embodiment of a 

storage peripheral computer device, such as a hard disk computer system designed in accordance with the present 

drive, which is connected to the host computer. invention which uses a peripheral bus, in which relocatable 

In another embodiment of the computer memory storage expansion BIOS location addresses are allowed, to connect 

medium, the medium is a floppy disk or another such a peripheral computer device to a host computer; 

medium, and the BIOS contained on the medium is trans- 30 FIG. 10 is a flow chart illustrating the details of a first 

ferable to the mass memory storage peripheral computer embodiment of how an expansion BIOS as shown in FIG, 9 

device. In this embodiment, the BIOS contained on the is loaded into system RAM of a host computer in accordance 

medium may be updated and revised BIOS associated with with the present invention; 

at least a portion of the computer system such as expansion piG. 11 is a flow chart illustrating the details of a second 

BIOS associated with a particular peripheral computer embodiment of how an expansion BIOS as shown in FIG. 8 

device connected to the system or system BIOS associated is loaded into system RAM of a host computer in accordance 

with the host computer. Alternatively, the BIOS contained with the present invention. 

on the medium may be expansion BIOS associated with a FIG UA ^ a flow cfaan moating how, in accordance 

particular peripheral computer device being connected to the ^ with the mvein ion,graphics are loaded from a mass memory 

computer system. storage device into video memory during the startup of a 

BRIEF DESCRIPTION OF THE DRAWINGS ^^J*?***"* , . ■„ . • k • 

FIG. 12B is a flow chart illustrating how, in accordance 

The features of the present invention may best be under- with the invention, operating data is loaded from a mass 

stood by reference to the following description of the 45 memory storage device into system during the startup of a 

presently preferred embodiments together with the accom- computer system, 
panyine drawings in which: 

t"*t/"> 1 . , 1 c DETAILED DESCRIPTION OF THE PRESENT 

FIG. 1 is a block diagram of a prior art computer system INVENTION 
using a PCI bus to connect a peripheral computer device to 

a host computer; 50 Referring to FIG. 5, the present invention will initially be 

FIG. 2A is a diagrammatic illustration of a prior art described in terms of an arrangement for allowing a host 

expansion BIOS containing multiple code images; computer to operate a particular peripheral computer device, 

™„ . . . .. . 4 . ... , # . r f the operation of which requires the host computer to obtain 

FIG. 2B is a detailed diagrammatic illustration of one of ^ BIQS ^ oci 2 d wilh the particular peripheral 

the code images shown in FIG. 2A which makes up part of sj ^ device and load ^ mQS {a{0 a system 

the prior art expansion BIOS; M shown [n mG ^ fl computer system 100 des igned 

FIG. 2C is a detailed diagrammatic illustration of a ^ accordance with the present invention includes a host 

configuration space memory of a PCI peripheral device; computer 102 having system BIOS 104 which is used to 

FIG. 3 is a flow chart illustrating a prior art sequence used operate host computer 102 and having RAM 106 associated 

by a typical PCI -based system to determine whether the 60 with host computer 102. System BIOS 104 is stored in 

system includes any peripheral devices which require the system ROM 108 within host computer 102. A peripheral 

loading of an expansion BIOS into system RAM of a host bus 110 is connected to host computer 102 and RAM 106 

computer. using a host bridge 112. A peripheral computer device 114 

FIG, 4 is a flow chart illustrating the details of how a prior is connected to host computer 102 using peripheral bus 110. 

art expansion BIOS associated with a particular peripheral 65 Host computer 102, system BIOS 104, RAM 106, ROM 108 

computer device is loaded into system RAM of a host and host bridge 110 are made up of any suitable and readily 

computer; providable components which allow host computer 102 and 
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RAM 106 to be connected to peripheral bus 110 using bridge device 114 also includes a configuration space memory 138 

112. These components include, but are not limited to, any having a configuration register 140 which contains informa- 

conventional 486, Pentium®, Power PC®, or RISC-based tion including a requested size or amount of system memory 

components. Although host computer 102, RAM 106, and for mapping the expansion BIOS similar to that described 

host bridge 112 are shown having a particular configuration 5 above for the prior art device 18 of system 10. However, in 

relative to one another, it should be understood that this is accordance with the present invention, the requested size 

not a requirement of the present invention. Instead, these specifies the amount of memory space required within the 

components may be interconnected in a variety of specific host computer to map both the first portion 120 of the 

configurations and still remain within the scope of the expansion BIOS and the second portion 128 of the expan- 

invention so long as the peripheral computer device 114 is 10 sion BIOS associated with peripheral computer device 114. 

connected to these components using peripheral bus 110 as Although FIGS. 6Aand 6B illustrate ( only one oodeimage* ; 

described hereinafter. making ^t^first~po^ib^l20"ald^second portion 128~6f 

Peripheral bus 110 may be any suitable and readily the expansion BIOS7 It should be understood that first 

providable peripheral bus in which relocatable expansion portion 120 and s econd portionjL28 of the expansion BIOS 

BIOS located addresses are allowed. One preferred embodi- 1S cmay~include multiple~images, jw ith each of A e im^ges> 

ment of such a peripheral bus is a PCI bus. However, it 'ccjre^poM^ 

should be understood that a wide variety of peripheral buses, ^Hicfa~lbe~3evice m ay. be_ajtached^This'multiple image 

such as other parallel buses, serial buses, or multiplexed approach would allow the same device to be attached to a 

buses, would also fall within the scope of the present variety of systems using di fferent com puter architectures 

invention. As described in detail above in the background, if 2 o wmcD correspond to the flifferenLcod e ima ges: If multiple 

a PCI bus is utilized, the PCI specification dictates how any code images are being provided, the requested size infor- 

expansion BIOS associated with a particular peripheral mation stored in configuration register 140 of configuration 

computer device is loaded into RAM 106 of the host system. space 138 includes enough space for all of the first and 

Other peripheral bus configurations have corresponding second portion of the code images, 

specifications, and therefore, the present invention will be 2 5 Now that the elements of this first embodiment have been 

described in detail assuming that a PCI bus is being used to described, the operation of this embodiment will be 

connect peripheral computer device 114 to host computer described in detail. When overall system 100 is first 

102. The application of the invention to other peripheral bus switched on, the system initially is operated in the same 

configurations will become clear to those skilled in the art in manner as typical system 10 which was described in detail 

view of this disclosure. Although the peripheral bus will be 30 in reference to the flow chart of FIG. 3. However, once the 

described throughout this specification as being a PCI bus, POST code checks system 100 for peripheral devices and 

this is not a requirement. Any peripheral bus which requires determines that there is a peripheral device which includes 

the mapping of the expansion BIOS location addresses into expansion ROM, in this case device 114, the operation of 

the system memory rather than allowing fixed, hard-wired system 100 begins to differ from the typical system 

expansion BIOS location addresses would equally apply. 35 described in reference to the flow chart of FIG, 4. Therefore, 

In a first embodiment of the present invention, peripheral the operation of system 100 after this point will be further 

computer device 114 is a mass memory storage peripheral described in reference to the flow chart of FIG. 7 which 

computer device having mass memory storage 116 such as would replace the flow chart of FIG. 4 described above for 

a hard disk drive or a compact disk player. Device 114 typical PCI-based system 10. 

requires an expansion BIOS associated with the device to be 40 Starting at decision block 54 of FIG. 7 in which the POST 

loaded into the host computer in order to properly initialize code determines if peripheral device 114 has an expansion 

and operate device 114. Although a hard disk drive and a BIOS, the POST code writes to and reads from the configu- 

compact disk player are specifically mentioned, peripheral ration register 140 of configuration space memory 138 of 

computer device 114 may take the form of any other mass peripheral device 114 to determine if an expansion BIOS is 

memory storage device and still remain within the scope of 45 present on the device and, if so, how much memory space is 

the invention. Mass memory storage peripheral computer requested. Once it is determined that this is an expansion 

device 114 includes a small amount of ROM 118. In BIOS, as indicated by block 146 of FIG. 7, the POST code 

accordance with the present invention, ROM 118 includes determines an acceptable address to map the expansion 

only a first portion 120 of the expansion BIOS which is BIOS to and writes that address to the configuration register 

associated with device 114. 50 140 of configuration space memory 138 on peripheral device 

Referring to FIG. 6A, when using a PCI bus, first portion 114. In block 148, the POST code then enables expansion 

120 of the expansion BIOS includes a configuration header BIOS ROM decoding on the device in a manner similar to 

122, a small amount of initialization code 124, and a check that described above for system 10, 

sum 126. The specific information in the configuration Next, in accordance with the presenl invention, peripheral 

header may vary depending on the bus being used; however, 55 device 114 maps first portion 120 of the expansion BIOS 

the information would be stored according to the protocol of stored in ROM 118 to the system memory address starting 

the bus being used. In a preferred version of this at the address the POST code wrote to configuration register 

embodiment, first portion 120 is a very small portion of the 140 in configuration space memory 138 on device 114 as 

overall expansion BIOS; for example, less than IK bytes in indicated in block 150. Device 114 sets up its internal 

size. A second portion 128 of the expansion BIOS associated 60 address decoder to decode the entire memory address range 

with device 114 is stored in mass memory storage 116. As requested by register 140 to which the ROM 118 is mapped, 

shown in FIG. 6B, second portion 128 of the expansion even though only a small portion is actually in ROM 118 of 

BIOS includes any data structure 130 which may be part of device 114. Because first portion 120 of the expansion BIOS 

the expansion BIOS, any runtime code 132 which may be stored in ROM 118 of device 114 is substantially smaller 

necessary to operate device 114 during the operation of the 65 than the requested amount of space requested by register 140 

system, any initialization code 134 necessary to initialize for the overall expansion BIOS as described above, faked 

device 114, and a check sum 136. As shown in FIG. 6C, generated data is mapped to this excess system memory 
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space. This may be accomplished in a variety of ways. For In a second embodiment also illustrated in FIG. 5, the 

example, a single data location on ROM 118 may be mapped particular peripheral computer device may take the form of 

to all of the excess system memory space, thereby requiring a device or expansion card other than a mass memory 

only a single data location to fill the entire excess system storage peripheral computer device. Examples of such a 

memory space. Alternatively, a small data generating code 5 device are video cards, multimedia cards, network cards, or 

may be provided which is capable of generating data pat- any other expansion card or peripheral device which 

terns on the fly. In this example, the data generating code is includes an expansion BIOS. In this embodiment, computer 

mapped to the excess memory space such that when it is system 100 includes a peripheral computer expansion card 

accessed, the data generating code generates the accessed 0 r device 174 which requires an associated expansion BIOS 

amount of data. iQ t 0 oe loaded into the host computer in order to initialize 

Although only two specific examples of how this excess and/or operate expansion card 174. In the same manner as 

RAM space is filled are described, a variety of other specific described above for device 114, expansion card 174 includes 

methods may be used, all of which would fall within the a R0M 176 which contains a first portion 178 of the 

scope of the present invention. In a preferred version, all .of expansion BIOS associated with expansion card 174. 

the u eX ^x^l SpaCe ma r PCd l ° 3 Sl i§n /!! ° D 35 However, in this embodiment, a second portion 180 of the 

within ROM 1^ expansion BIOS associated with expansion card 174 is 

sion BIOS. This data location presents a zero as the data for mem device ^ 

that location. By doing this, all of the excess RAM space is „ . . . - . J F DT<n . c - 

filled with zeros Since all of the excess RAM space is filled ^ * c ° f the ex P ansl0D * I0S for expansion 

with zeros, this excess space does not affect the check sum card 174 10 * stored m m f s memory storage 116 of a mass 

counter, and the check sum 126 may be placed at the end of 20 memory storage peripheral computer device 114. The opera- 

first portion 120 of the expansion BIOS. tion of thls embodiment would be identical to the first 

As indicated in block 152, the POST code reads through embodiment described above except that the small initial- 
the expansion BIOS by reading the memory locations to 1211100 code provided within first portion 178 contained in 
which the expansion BIOS was mapped, searching for an R OM 176 would operate device 114 and access second 
appropriate expansion BIOS code image, in this case the 25 portion 180 of the expansion BIOS associated with expan- 
only code image included in first portion 120 of the expan- sion card 174 contained within mass memory storage 116. 
sion BIOS. If an appropriate code image is not found, as Although both the first and the second embodiments 
shown in decision block 154, the sequence returns to block described so far have included ROM 118 and ROM 176 
56 to see if there are additional devices to be configured. located on the peripheral computer device which requires 
However, if a proper code image is found, the sequence 30 the loading of expansion BIOS in order to be initialized 
moves to block 156 in which the POST code determines a and/or operated by the host system, this is not a requirement, 
memory location within host system RAM 106 to copy the Alternatively, the ROM containing the first portion of the 
expansion BIOS code into from the device ROM 118. The expansion BIOS may be provided at other locations within 
POST code then in block 158 copies the code image from the overall system. One example of this may be a situation 
the device ROM 118 into system RAM 106. This copying 35 in which a highly integrated system is provided as a corn- 
includes first portion 120 of the expansion BIOS and the plete package including a particular grouping of peripheral 
faked generated data described in detail above. As indicated devices. Referring to FIG. 5, in this situation, ROM 118 and 
in block 160, the POST code calls the initialization code 124 176 which contain the first portion of the expansion BIOS 
of the first portion 120 of the expansion BIOS now in system for device 114 and device 174, respectively, may be pro- 
RAM 106 and runs initialization code 124. 40 vided as part of the system ROM 108. The majority of the 

In accordance with the invention and as indicated in block expansion BIOS associated with the peripheral devices 

162, initialization code 124 contains just enough code to included in the complete package, in this example device 

activate mass memory storage peripheral computer device 114 and 174, is stored within a mass memory storage device 

114 and load second portion 128 of the expansion BIOS into such as a hard disk drive in the same manner as described 

system RAM 106. Initialization code 124 runs initialization 45 above. The expansion BIOS ROM required to be included 

code 134 of second portion 128 now in host RAM as shown with the system ROM 108 would only need to be large 

in block 164. Although in the example given initialization enough to contain code that would operate the hard drive and 

code 124 includes only enough code to activate mass turn over control to the initialization code stored in the hard 

memory storage device 114, load second portion 128, and drive. All of the expansion BIOS associated with the various 

run initialization code 134, this is not a requirement of the 50 peripheral devices included in the package could then be 

invention. Initialization code 124 may include more code so loaded into the RAM of the host system in the same manner 

long as at least a portion of the expansion BIOS is stored on as described above. However, in this situation, the first 

mass memory storage 114. However, the preferred embodi- portion of the expansion BIOS for each peripheral device is 

ment would minimize the amount of code stored in ROM provided as part of the system BIOS and therefore the 

118, thereby reducing the cost of the ROM as much as 55 system BIOS (that is POST in the previous examples) does 

possible. In block 166, initialization code 134 further con- not need to search for these peripheral devices as described 

figures peripheral device 114 and installs system level above. 

software support including interrupt handlers, device spe- In accordance with another embodiment of the present 

cific data, etc. Once initialization code 134 is finished, invention, this general approach may be used to reduce the 

initialization code 134 returns control of the system to the 60 amount of system ROM required within the host computer. 

POST code as shown in block 168. In block 170, the POST Still referring to FIG. 5, in this embodiment, system BIOS 

code performs any final initialization such as marking the 104 stored in system ROM is only a small first portion of the 

portion of the system RAM 106 used to store the expansion overall system BIOS used by host computer 102. A second 

BIOS remaining in system RAM after initialization code portion 182 of the system BIOS is stored within mass 

134 has run as read only. And finally, at this point, the 65 memory storage 116 of mass memory storage device 114 in 

sequence returns to decision block 56 to see if there are any the same manner as described above for the peripheral 

more devices present to be configured. device expansion BIOS. With this arrangement, system 



03/02/2004, EAST version: 1.4.1 



US 6,401,198 Bl 

13 14 

ROM 108 only needs to be large enough to store enough specified to boot off of the floppy drive first, CD ROM drive 

code to activate mass memory storage device 114 and load second, the hard drive third, or any order could be used, 

second portion 182 into system RAM 106. enabling and disabling the system speaker, selecting the boot 

Referring now to the flow chart in FIG. 8, the operation display or video display device, for example with a com- 

of a system in which the system BIOS is divided into a first 5 puter that has a LCD display or a CRT, the LCD could be 

portion stored in system ROM 108 and second portion 182 selected or a TV port, all could come on when you boot or, 

stored within mass memory storage 116 of mass memory for example, projection display, any or all could be simul- 

storage device 114 will be described in detail. In this taneously displayed. 

arrangement, after the computer is turned on, as indicated in Store the current memory size of the host, total memory 

block 184, the first portion of the system BIOS stored in 10 size, cache RAM or cache memory size, store the current 

system ROM 108 finds and configures mass memory storage extended memory size of the host, store the host CPU size 

device 114 (block 186). As indicated in block 188, the first and the host CPU speed, store the host system number and 

portion of the system BIOS includes code which determines the BIOS version number, store the selection of quiet boot, 

an acceptable address to load second portion 182 of the enable or disable the television port to allow data to display 

system BIOS into within system RAM 106. Next, in blocks 35 on TV, select the type of TV signal, for example PAL or 

190 and 192, the first portion of the system BIOS code loads NTSC, serial port IRQ (interrupt request line) address, serial 

the second portion 182 of the system BIOS from mass port communication port number, COM1, COM2 and 

memory storage device 114 into system RAM 106 and runs COM3, select which COM port used for the wireless com- 

the second portion of the system BIOS which is now in munication of device to the computer such as an infrared 

system RAM. At this point, the second portion of the system 2 n device, parallel port address such as LPT1, LPT2, disable 

BIOS takes control, as indicated in block 194, and the the address of the above ports, set up operation mode of 

system continues to operate in the same manner as if the parallel port (standard mode, bidirection mode and ECP 

entire system BIOS were provided within ROM 104. mode). 

It should be understood that once the second portion of the Typically, if ECP mode is selected, usually then the ECP 
system BIOS has been loaded into RAM and executed, the 25 channel would be selected, also enable and disable pass- 
system may continue in accordance with the above words such as the user password and the superior password, 
described arrangements for loading any expansion BIOS also set what the password should be, also determining if a 
associated with peripheral devices connected to the system. password is required on boot, enable or disable the password 
Alternatively, the expansion BIOS may be loaded as will be on resume, store password protection for diskette of a floppy 
described in detail hereinafter. Using this overall approach, 30 drive, fixed disk boot protection can be set to normal or write 
the majority of the system BIOS, along with the majority of, protected, enable the integrated hard drive interfaces, select 
or even all of, the expansion BIOS of peripheral devices primary integrated adapter, secondary integrated adaptor, 
connected to the system may be stored within the mass both or disable, enable or disable the floppy disk controller, 
memory storage of a mass memory storage device connected configure the serial port, disable, enable or auto, select 
to the system rather than being stored in ROM. This elimi- 35 disable, enable and auto for serial port configuration, select 
nates the majority of the cost associated with the BIOS ROM disable, enable and auto for infrared port configuration, 
required for the system BIOS and expansion BIOS in a select mode for infrared port or wireless port, IRDA or FIR, 
typical computer system. Furthermore, taking this same select the base I/O address for the infrared port, select the 
basic concept a step further, additional components of a configuration of the parallel port to enable, disable or 
typical computer system may also be eliminated by storing 40 automatically configure the path by either the system BIOS 
the information stored in these components within the mass or the operating system, select the mode of parallel port 
memory storage device. For example, battery backed-up where the modes include normal, bidirectional ECP or EPP 
memory which may include system configuration mode, select the configuration of the modem port to enable, 
information, passwords, system time, system date, floppy disable or automatically configure the port by either the 
drive configuration data, size, diskette type including 45 system BIOS or operating system, configure power 
disable, 1.44 MB at 3.5 inch, 1.25 MB at 3.5 inch, 7.20 KB management, configure the power management mode, 
at 3.5 inch, 1.2 MB at 5.25 inch, 3.60 KB at 5.25 inch and always (power management for AC and battery power), 
capacity, diskette write protect enable/disable, hard disk battery only, disable (no power management), maximum 
capacity, configuration data and size, CD ROM and DVD performance to allow power conservation with optimal 
configuration data, size and capacity, mass storage device 50 system performance, maximum power saving to allow most 
detection method to the type of hard drive, CD ROM and/or power saving at expense of system performance, custom, to 
DVD peripheral that may be attached to the computer, or any allow custom setting for different power management fea- 
other information typically stored in ROM or battery tures including smart CPU mode with off and on options, 
backed-up memory may also be eliminated by storing this standby time out with disable and a predetermined period of 
information on the mass memory storage device and access- 5s time, suspend time out with disable and predetermined 
ing it during the startup of the system as described above. period of time, suspend with save to disk or suspend with 

The user typically has the option of setting up the BIOS save to RAM, resume; resume on modem, ring with enable 

by selecting either auto (automatic) or manual. If the user or disable ring, resume on time of day, setting the time to set 

selects manual, then the user usually may select at least one the resume time, battery low suspend with an enable or 

of the following: type of drive, either CD or DVD, a number 60 disable feature, inactivating timer, enable, disable, resume 

that corresponds to a proprietary drive number or a user- on alarm with enable or disable by setting the alarm time and 

defined configuration that allows the user to select the alarm date, configure time-out function with disable with a 

number of cylinders, number of heads, sector or track, write fixed amount of time, stand-by time out, 5-Volt suspend time 

precompensation, boot sequence, select the order that the out, 0-Volt suspend time out, hard disk time out, video time 

system would try to boot from each of storage devices 65 out, language, select primary IDE master, primary IDE 

installed in the computer such as disk drive floppy devices, slave, secondary IDE master, secondary IDE slave, all that 

CD ROM drives, and DVD devices, for example, it can be is stored is what is found, select plug-in plug operating 
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memory storage may be easily upgraded. In the case in 
which the mass memory storage is a hard disk drive, the 
portion of the expansion BIOS may be stored in a portion of 
the mass memory storage which is not user accessible. A 
variety of methods may be used to protect this portion of the 5 
hard drive from being accessed during normal operation of 
the hard drive. In this situation, a utility program may be 
provided which allows this protected portion of the hard 
drive to be accessed when and if an update or correction of 
the portion of the expansion BIOS stored on the hard drive 30 
is desired. All of the above described embodiments are able 
to take advantage of this ability to update and revise the 
portion of the expansion BIOS which is stored in the mass 
memory storage of the mass memory storage peripheral 
device of the system. 15 

The general approach of storing at least a portion of the 
expansion BIOS on mass memory storage also allows the 
host system to be configured differently for different situa- 
tions. An example of this would be when the system is being 
used for running a particular game or application which may 2 o 
function better when the system is configured in a manner 
different than during the normal operation of the system. In 
this situation, the mass memory storage device may be a 
compact disk player, and the game or application may be 
provided on a compact disk. Depending on which of the 2 s 
above described approaches is being used, the compact disk 
itself would contain at least a portion, if not all, of the 
expansion BIOS. This expansion BIOS on the compact disk 
would include initialization and runtime code which would 
optimize the operation of the system for the specific game or 30 
application that is being run. 

By storing a portion of the expansion BIOS and/or system 
BIOS on the mass memory storage of the mass memory 
storage peripheral device, a much larger expansion and/or 
system BIOS may be provided without increasing the cost of 35 
the peripheral device and/or the system. As described above, 
this general concept of storing information required during 
the startup of the system may include a variety of operating 
data, text, or other information that increases the function- 
ality of the system during the startup of the system. One 40 
specific example of this is the ability to present more 
elaborate graphics displays during the startup of the system 
without having to include a large amount of ROM some- 
where within the system in order to contain the desired 
graphics information. 45 

Referring to FIG. 12A, the operation of a computer 
system in accordance with the invention will be described 
which includes the capability of providing particular graph- 
ics information to the system during the startup of the 
system. As indicated in blocks 222 and 224, the computer is 50 
turned on and the initialization code of the BIOS associated 
with the system takes control of the system. This BIOS may 
be any of the various BIOS arrangements described above. 
At this point, as indicated by decision block 226, the 
initialization code of the BIOS checks to see if the computer 55 
system contains video graphics memory. If there is no video 
graphics memory present, as indicated in block 234, the 
initialization code of the BIOS goes on configuring the 
system. However, if there is video graphics memory present, 
the current video memory plane is set active and the current 60 
video memory plane image is read from the mass memory 
storage device directly into video memory as shown in 
blocks 228 and 230, respectively. The initialization code of 
the BIOS then checks to see if there is another video 
memory plane to be read as indicated in decision block 232. 65 
If so, blocks 228 and 230 are repeated until there are no more 
video memory planes to be read. 
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Referring now to FIG. 12B, the same basic approach 
described above for the graphics example may be used to 
provide other operating data to the system. This operating 
data may include, but is not limited to, system configuration 
information, data, text, passwords, or any other information 
that may provide some purpose during the startup of the 
system. As was described above for FIG. 12 A, the computer 
is turned on and the initialization code of the BIOS associ- 
ated with the system takes control of the system as indicated 
in blocks 222 and 224. At this point, as indicated by decision 
block 236, the initialization code of the BIOS checks to see 
if the mass memory storage device contains operating data 
to be loaded into the system. If there is no operating data 
present, as indicated in block 234, the initialization code of 
the BIOS goes on configuring the system. However, if there 
is operating data present, the initialization code determines 
the memory location to load the operating data into, and the 
operating data is read from the mass memory storage device 
into system RAM as shown in blocks 238 and 240, respec- 
tively. The initialization code of the BIOS then checks to see 
if there is any more operating data to be read as indicated in 
decision block 242. If so, blocks 238 and 240 are repeated 
until there is no more operating data to be read. 

As mentioned above, by using the approach described for 
FIGS. 12A and 12B, operating data or graphics may be 
provided to the system during the startup of the system 
without requiring additional ROM storage space for this 
information. This allows much more information to be 
provided during the system startup without increasing the 
cost of the system or peripheral. This approach also allows 
the cost of ROM or other forms of memory storage such as 
battery backed-up memory currently used for this purpose to 
be eliminated, reducing the cost of the system. 

Although the peripheral bus has been described through- 
out as being a PCI bus, this is not a requirement. As 
mentioned above, any peripheral bus which requires the 
mapping of the expansion BIOS location addresses into the 
system memory rather than allowing fixed, hard- wired 
expansion BIOS location addresses would equally apply. 
Also, it should be understood that in the embodiments which 
eliminate entirely the expansion BIOS ROM on a particular 
peripheral device, the particular peripheral device may still 
include ROM for other purposes and still remain within the 
scope of the invention. 

Although only a few specific examples of providing an 
arrangement in which at least a portion of the BIOS or 
operating data is stored in the mass memory storage of a 
mass memory storage peripheral computer device have been 
described, it should be understood that the invention may 
take on a wide variety of other specific forms. For example, 
in a system in which several peripheral devices are con- 
nected to the host computer, the expansion BIOS for all of 
the devices may be stored on the mass memory storage 
device. In this example, the first portion of the expansion 
BIOS for the mass memory storage device may be loaded 
into a memory buffer as described above or may be stored 
in a small expansion BIOS ROM as described above. The 
second portion of the expansion BIOS for the mass memory 
storage device along with the expansion BIOS for all of the 
other peripheral devices may be stored in the mass memory 
storage of the mass memory storage device and may be 
accessed using the first portion of the expansion BIOS for 
the mass memory storage device. Therefore, the present 
examples are to be considered as illustrative and not 
restrictive, and the invention is not to be limited to the details 
given herein, but may be modified within the scope of the 
appended claims. 
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system including yes and no, reset configuration data includ- entire memory address range requested by its configuration 

ing yes and no options, select system speed fast and com- space even though there is no ROM in device 202. 

patible to set the speed of the memory cache, select error As was described for previous embodiments, the POST 

correction control (ECC) configuration, sets the memory code reads through the expansion BIOS by reading the 

ECC state including ECC or non-ECC, select resource 5 memory locations to which the expansion BIOS was 

configuration memory reservation to reserve specific mapped, searching for an appropriate expansion BIOS code 

memory blocks, IOQ to reserve specific IOQs, select key- image (block 152). If an appropriate code image is not 

board configuration including NUM lock to set the power on found, the sequence returns to block 56 to see if there are 

state so that NUM lock is active or non active, select key- additional devices to be configured. However, if a proper 

board rate to select the keyboard repeat rate (in per sec), a0 code image is found, the sequence moves to block 212 in 

keyboard delay select delay before repeat of the keys, select which the POST code determines a memory location within 

video configuration palette snooping to enable or disable, nost system RAM 106 to copy the expansion BIOS code to 

DMI event logging including event log capacity, event log & om memory buffer 206 of device 202. The POST code then 

visibility, DMI event log data, clear the DMI event log, C0 P ies the ^ ™age from memory buffer 206 of device 

event logging disable or enable, mark the DMI events as 1S 202 into system RAM 106 as indicated in block 214. Jhis 

read, select the setup password, restore on power loss to ? cludes the >}f P°<J 10D ° u f * e expansion BIOS and 

restore the last state before power loss occurred, stay off to ih % fa ^ d . d * ta ab< \ d ***** ^ G ' t 

. a iM u • j indicated in block 160, the POST code calls the initialization 

keep power off until power button * pressed, power on code ^ ^ fifSt ion of ^ e ion 

which restores power to the system quick boot mode enable mQS nQW [n ffl ^ 106 £ d mns ^ mitia f ization 

or disable to skip certain tests while booting. 20 code m remainder of the operation of this embodiment is 

In another embodiment of the present invention, the need identical to that described above for the flow chart of FIG. 

for an expansion BIOS ROM associated with a particular 7 

peripheral computer device is eliminated altogether. Refer- Alternatively, in another version of this embodiment, 

ring to FIG. 9, an overall system 200 includes host computer memory buffer 206 may be mapped into the host system's 

102, system BIOS 104, system RAM 106, system ROM 108, 2 s memory as expansion BIOS for the entire expansion BIOS 

host bridge 112, and peripheral bus 110 as described for the image, eliminating the need to divide the expansion BIOS 

previous embodiments. System 200 also includes mass into first and second portions. Referring to the flow chart of 

memory storage peripheral computer device 202 having FIG. 11, this approach will be described. Blocks 54, 56,146 

mass memory storage 204. In this embodiment, all of the and 148 remain the same as the embodiment described 

expansion BIOS associated with device 202 is stored within 30 above for FIG. 10. However, in block 216, device 202 maps 

mass memory storage 204, As mentioned above for other its memory buffer 206 as expansion BIOS for the entire 

embodiments, device 202 may take the form of a hard disk expansion BIOS image into system memory starting at the 

drive, a compact disk player, or any other form of mass address the POST code provided to the configuration space 

memory storage. of device 202. Device 202 reads the expansion BIOS from 

Mass memory storage device 202 further includes a 35 its mass memory into its memory buffer and maps the image 
memory buffer 206 for storing data input and output as it is into system memory. If multiple images are provided, they 
transferred to and from mass memory storage 204. Memory are also mapped into system memory. The device sets up its 
buffer 206 is configured such that it appears to the host internal decoder to decode the entire memory range even 
system as if it is an expansion ROM installed on device 202 though there is no ROM on the device. Blocks 152, 154 and 
during the startup of the system. In accordance with the 40 212 are also identical to those described above for FIG. 10. 
present invention, device 202 also includes an intelligent However, in block 218, the POST code copies the appro- 
start-up arrangement 208. Start-up arrangement 208 senses priate expansion BIOS image which contains the entire 
when the system is being turned on and, in response to the expansion BIOS as read off of mass memory storage 204 
startup of the system arrangement 208, causes mass memory from memory buffer 206 of device 202 to system RAM 106. 
storage device 202 to quickly turn on and load at least a first 45 From this point on, the operation proceeds through blocks 
portion of the expansion BIOS into memory buffer 206. 76, 78, 80 and 82 in the same way as if the expansion BIOS 
Arrangement 208 is configured to load this first portion of had been loaded from ROM on the device as was described 
the expansion BIOS into memory buffer 206 quickly enough for the prior art system shown in the flow chart of FIG. 4. 
that it is available to the host system when POST checks Referring back to FIG. 9, another embodiment provides 
device 202 to see if it requires any expansion BIOS. This 50 an arrangement in which the expansion BIOS ROM asso- 
first portion of the expansion BIOS is similar to first portion ciated with a particular peripheral computer device other 
120 of the expansion BIOS for the first embodiment than a mass memory storage device is eliminated altogether, 
described above. In this embodiment, system 200 includes a peripheral com- 

Referring to FIG. 10, this embodiment is operated in puter expansion card or device 220 which requires an 

much the same manner as was described for the operation of 55 associated expansion BIOS to be loaded into the host 

the embodiment illustrated in the flow chart of FIG. 7. As computer in order to initialize and/or operate expansion card 

shown in FIG. 10, the first blocks 146 and 148 are the same 220. In the same manner as described above for device 202, 

as described above. However, in this embodiment after the the expansion BIOS associated with expansion card 220 is 

POST code enables expansion ROM decoding, block 150 of stored in mass memory storage 204 of device 202. The 

FIG. 7 is replaced with block 210 in which device 202 maps 60 operation of this embodiment would be identical to the 

its internal memory buffer 206 as expansion BIOS into embodiment described immediately above except that the 

system memory starting at the address the POST code initialization code stored within mass memory storage 204 

provided to the configuration space of the device. In the would include initialization and runtime code for expansion 

same manner as described in detail above for FIG. 7, faked card 220 as well as initialization code and runtime code for 

generated data is mapped to the excess system memory 65 device 202. 

space requested by the configuration space of device 202. One of the advantages of the present invention is that the 

Device 202 sets up its internal address decoder to decode the portion of the expansion BIOS which is stored with the mass 
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What is claimed is: 

1. A method for using a computer system including a host 
computer having system RAM and a mass memory storage 
peripheral computer device having mass memory storage 
which is connected to the host computer, the host computer 5 
using a BIOS to control its operation during the start-up of 
the computer system, a method comprising the steps of: 

providing access to the host computer during the start-up 
of the computer system for containing at least a portion 
of the BIOS; 

storing configuration data that corresponds to a configu- 
ration of the mass memory storage peripheral computer 
device within the mass memory storage of the mass 
memory storage peripheral computer device; 

during the start-up of the system, causing the host com- 
puter to access and obtain the portion of the BIOS; and 

by using the portion of the BIOS, causing the host 
computer to (i) access the mass memory storage of the 
mass memory storage peripheral computer device, (ii) 2 o 
obtain the configuration data which is located within 
the mass memory storage of the mass memory storage 
peripheral computer device, and (iii) store the configu- 
ration data within the system RAM. 

2. A method for using a computer system, as in claim 1, 2 s 
wherein said configuration data is date data. 

3. A method for using a computer system, as in claim 1, 
wherein said configuration data is time data. 

4. A method for using a computer system, as in claim 1, 
wherein said configuration data is data relating to reading or 30 
writing to/from a mass storage device. 

5. A method for using a computer system, as in claim 1, 
wherein said configuration data is data relating to type of the 
configuration data. 

6. A method for using a computer system, as in claim 1, 35 
wherein said configuration data is data relating to host data. 

7. A method for using a computer system, as in claim 1, 
wherein said configuration data is data relating to power 
management. 

8. A method for using a computer system, as in claim 1, 40 
wherein said configuration data is data relating to keyboard 
data. 

9. A method for using a computer system, as in claim 1, 
wherein said configuration data is data relating to start-up or 
initialization. 



10. A computer system including a host computer having 
system RAM and a mass memory storage peripheral com- 
puter device having mass memory storage which is con- 
nected to the host computer, the host computer using a BIOS 
to control its operation during the start-up of the computer 
system, comprising: 

a storage accessible to the host computer during the 

start-up of the computer system for including at least a 

portion of the BIOS; 
the mass memory storage having configuration data of the 

mass memory storage peripheral computer device; 
during the start-up of the system, the host computer being 

operable to access and obtain the portion of the BIOS; 

and 

by using the portion of the BIOS, the host computer being 
operable to (i) access the mass memory storage of the 
mass memory storage peripheral computer device, (ii) 
obtain the configuration data which is located within 
the mass memory storage of the mass memory storage 
peripheral computer device, and (iii) store the configu- 
ration data within the system RAM. 

11. A computer system, as in claim 10, wherein said 
configuration data is date data. 

12. A computer system, as in claim 10, wherein said 
configuration data is time data. 

13. A computer system, as in claim 10, wherein said 
configuration data is data relating to reading or writing 
to/from a mass storage device. 

14. A computer system, as in claim 10, wherein said 
configuration data is data relating to type of the configura- 
tion data. 

15. A computer system, as in claim 10, wherein said 
configuration data is data relating to host data. 

16. A computer system, as in claim 10, wherein said 
configuration data is data relating to power management. 

17. A computer system, as in claim 10, wherein said 
configuration data is data relating to keyboard data. 

18. A computer system, as in claim 10, wherein said 
configuration data is data relating to start-up or initialization. 
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(57) ABSTRACT 

A method and apparatus in the form of a peripheral device 
for d6wnl<5ading~firmware responsive~tb~T request by lin 
operatively connected client computer from a connected 
rjost^lTs^urce~td"the~periphe ral devioe~bf t he type~which 
has a non-volatile memory, the peripheral device being 
adapted to download the firmware having the operating 
instructions and data into the non-volatile memory with at 
least one backup image partition for storing basic configu- 
ration and utility operations relating to the firmware and at 
least one code image partition for storing the firmware. The 
method includes the steps of receiving- a- download~file~fo?J 
^heHr^uested firniware~from the cliepl computer, "saving a 
specific dataTimage of the file into one of the image partitions 
designated by the data image, performing an error check on 
the data image saved in the designated image partition, 
terminating the process if an error is found, and repeating the 
steps of the process for the next data image of said file if no 
error is found. 
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METHOD AND APPARATUS FOR 
DOWNLOADING FIRMWARE TO A NON- 
VOLATILE MEMORY 

The present invention generally relates to a method and 
an apparatus for downloading firmware from a connected 
host or a source requested by an operatively connected client 
computer, more particularly, it relates to a method and 
apparatus in the form of a peripheral device for downloading 
firmware into a non-volatile memory with a backup image 
partition and a code image partition. 

A peripheral device commonly stores its own configu- 
ration and operational codes for usage with a computer, 
which is generally stored as a firmware. The firmware is a 
collection of the essential programs for the peripheral device 
that remain in storage even when the system is turned off. 
The firmware is generally saved in the peripheral device 
using non-volatile memory or the programmable flash 
memory. Since the computers need to be upgraded in time, 
the firmware must also be upgraded for performance or to 
add new features. As a result, a new firmware must be 
downloaded and installed periodically by the users. 

The non-volatile memory of the firmware is generally 
divided into several partitions with specific storage defini- 
tions according to the type of information that is being 
stored. For example, there may be four partitions, specifi- 
cally the Basic Input/Output System ("BIOS") partition, the 
non-volatile data partition, the code image ("CI") partition, 
and the backup image ("BI") partition. In this case, the CI 
partition is used for storage of all the firmware. At the start 
of a download process, the BI partition stores the backup 
image of the firmware, which is the basic configuration and 
utility operations relating to the firmware. The code image of 
the firmware, which is the codes of the actual firmware, is 
then saved in the CI partition after a successful download of 
the backup image. 

If the download is successful, the backup image will not 
be used at all. Because the code image is generally much 
larger than the backup image, an error, such as a power 
failure, may occur during the download process of the code 
image. In that case, the information from the backup image 
is used to restart the downloading process from the step of 
downloading the code image instead of starting the down- 
load process at the very beginning. The backup image allows 
for a fail-safe method of downloading. 

Previous technology required that the backup image be 
executed during the download process before it could actu- 
ally be used. More precisely, the backup image's instruc- 
tions must first be carried out (i.e., the execution) before the 
peripheral device can actually use the basic configuration 
and utility operations saved in the BI partition to restart the 
download process in the event of a transmission interrup- 
tion. This was so because the backup image was saved in the 
non-volatile memory; but at the same lime, it was executed 
also from the non-volatile memory. Since the backup image 
did not take effect until execution, the transmission had to be 
interrupted while awaiting execution of the backup image. 
Then, the non-volatile memory switched back to the receiv- 
ing mode. 

One problem with this prior method was that the switch- 
ing and the interruption of the transmission caused errors in 
greater frequency. As a result, the download process was 
unreliable. 

Another problem was that the switch between the receiv- 
ing and executing mode, and then switching back to the 
receiving mode for the CI partition significantly slowed 
down the download process. 
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Yet another problem was that the prior method depended 
upon the use of a simple network management protocol 
("SNMP") and a trivial file transfer protocol ("TFTP"), 
which was often very inflexible. As a result, the prior method 
5 does not work well with the more standard software avail- 
able today, such as hypertext transfer protocol ("HTTP") and 
file transfer protocol ("FTP"). 

Still another problem was that the prior method depended 
upon the SNMP Set Community Name for its security, 
30 which is transmitted in clear text over the network. Thus, the 
prior method was insecure because no cryptographic secu- 
rity existed. 

Accordingly, an object of the present invention is to 
provide an improved method for downloading firmware to a 
15 peripheral device that does not require execution of the 
fail-safe data image until the end of the download process. 

Another object of the present invention is to provide an 
improved method for downloading firmware to a peripheral 
device that is more reliable and faster. 
20 Still another object of the present invention is to provide 
an improved method for downloading firmware to a periph- 
eral device that is more secure. 

A further object of the present invention is to provide an 
improved method for downloading firmware to a peripheral 
25 device that can accommodate the present standard software. 

BRIEF SUMMARY OF THE INVENTION 

The present invention generally relates to a method and an 
apparatus in the form of a peripheral device for downloading 

30 firmware responsive to a request by an operatively con- 
nected client computer from a connected host or a source, 
and more particularly to a method and peripheral device for 
downloading firmware into the non-volatile memory with a 
BI partition and a CI partition. The present method and 

35 peripheral device does not require the execution of the 
fail-safe data image, such as the backup image discussed 
earlier, during the download process in order for it to take 
effect, resulting in a more reliable, flexible, and faster 
method. 

40 

In accordance with this invention, the peripheral device 
first receives a download file for the requested firmware 
from the client computer. Then, it saves a specific data image 
of the file into one of the image partitions designated by the 
45 data image, and an error check is performed for the data 
image. If an error with the data image occurs, then the 
peripheral terminates the process. However, the process is 
repeated for the next data image of the file if no error is 
found. 

50 Other objects, features and advantages will become 
apparent upon reading the following detailed description, in 
conjunction with the attached drawings, in which: 

FIG. 1 is a schematic diagram of an exemplary connection 
between a peripheral device and a client computer receiving 
55 from a host or a source in which the present invention may 
be implemented; and, 

FIG. 2 is a flowchart illustrating the preferred subroutine 
of the peripheral device during the download process. 

60 TABLE OF ACRONYMS 

The patent references several acronyms. The following 
table is provided to aid the reader in determining the 
meaning of the several acronyms: 
65 BIOS-Basic Input/Output System 

BI«Backup Image 

Cl-Code Image 
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CROCyclic Reduadancy Code Check 

FTP=File Transfer Protocol 

HTTP=Hypertext Transfer Protocol 

RAM=Random Access Memory 5 

SNMP*=Simple Network Management Protocol 

TFTP«Trivial File Transfer Protocol 

DETAILED DESCRIPTION 

Broadly stated, the present invention relates to a method 10 
and apparatus for downloading firmware from a connected 
host or a source requested by an operatively connected client 
computer, allowing for a fail safe download process that 
does not require the execution of the backup image data 
before the code image can be downloaded. The present 
process accommodates the storing of the complete requested 
firmware file in the no n -volatile memory or programmable 
flash memory, and any execution processes are done using 
the random access memory ("RAM") instead of flash 
memory. Thus, the present method avoids switching 
between the receiving mode and the execution mode during 
the download process. 

Turning now to FIG. 1, a schematic diagram of an 
exemplary connection between a peripheral device and a 25 
client computer receiving from a connected host or a source 
is shown. Several examples of the source or the connected 
host are shown, but the implementation of the present 
invention can vary, and an array of implementations are 
within the scope of the present invention. In this example, a 3Q 
peripheral device 10 is connected to a client computer 12. 
The client computer 12 is connected to a connected host or 
a source 14, such as another computer 16, a CD Rom drive 
18, or the Internet 20, for receiving data, which are to be 
transmitted to the peripheral device 10. However, the client 35 
computer 12 may not necessarily be connected to another 
computer 16 or the Internet 20. For example, the client 
computer 12 may be receiving data from a CD Rom drive 
20. In fact, the firmware file can also be stored in the hard 
drive (not shown) of the client computer 12. 40 

FIG. 2 shows a flowchart of the preferred subroutine of 
the peripheral device 10 during the download process. 
Before the start of the process (block 22), the peripheral 
device 10 must be operatively connected to the client 
computer 12 (block 24). In addition, the client computer 12 45 
must initiate the start of the subroutine by sending the 
download file to the peripheral device 10 (block 26). After 
the initiation, the peripheral device 10, at first, receives only 
a few bytes of the download file (block 28) for checking the 
data format (block 30) to ensure that a proper file is being 50 
received. If the formal of the download file is not proper 
(block 32), the peripheral device 10 sends an error message 
to the client computer 12 (block 34) and the download 
process is then aborted (block 36). On the other hand, if the 
format of the download file is proper (block 32), the periph- 55 
eral device 10 starts saving the backup image of the down- 
load file in the BI partition of the non-volatile memory 
(block 38). 

As noted earlier, the backup image contains the basic 
configuration and utility operation relating to the download 60 
and firmware, which is used as a fail-safe device in the event 
that the download process is interrupted. The backup image 
is preferably the first data image to be saved in the process, 
however, it is not necessary for implementation of the 
present invention. For example, there may be instances 65 
when the download file is divided into more than just the 
backup image and code image, and the third data image may 
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be the smallest in size. In such a case, it may be more 
desirable to download the third data image first since it is the 
smallest part of the download file. There may also be other 
instances where downloading the backup image first would 
be inefficient or impracticable. Notwithstanding these other 
possibilities, downloading of the backup image first is still 
preferred in the present invention, although it is unnecessary. 
Nonetheless, the order is generally defined by the download 
file rather than the peripheral device 10. 

The peripheral device 10 continues saving the backup 
image into the BI partition (block 38) until the download is 
completed (block 40). When the download is complete 
(block 40), the peripheral device 10 performs an error check 
on the backup image (block 42). More specifically, it is 
preferred that a cyclic redundancy code check ("CRC") is 
used for the error check. If an error is found (block 44), an 
error message will be sent to the client computer 12 (block 
34) and the download process is terminated (block 36). 

Otherwise, the peripheral device 10 continues to save the 
code image into the CI partition (block 46), The saving of 
the code image (block 46) continues until completion (block 
48), which is followed by another error check specifically 
for the downloaded code image (block 50). Similarly, the 
CRC is preferred, but other data error checks may be used 
and are within the scope of the present invention. An error 
message is again sent out to the client computer (block 34) 
if an error is found by the CRC (block 52), and the download 
process is aborted as a result (block 36). But if an error is not 
found (block 52), the peripheral device 10 sends a download 
successful message to the client computer 12 (block 54). The 
peripheral device shuts down (block 56) to restart in order to 
execute the downloaded firmware (block 58) and the process 
is finished (block 60), 

The code image represents the actual firmware of the 
download file. To distinguish the code image from the 
backup image, the code image is the part of the file that the 
peripheral device 10 uses for the actual upgrade. On the 
other hand, the backup image is information that the periph- 
eral device 10 uses if there is a break in the download 
process of the code image. Although in this example, only 
the backup image and the code image are shown. The 
present method contemplates downloading other data image 
and are within the scope of the present invention. 
Furthermore, the labeling of the backup image and code 
image is arbitrary and has no effect on the present invention. 
Thus, other names for the plurality of memory partitions 
may be used and are also within the scope of the present 
invention. It is further contemplated that the present inven- 
tion can download firmware having more than two data 
image types. 

From the foregoing description, it should be understood 
that an improved method and peripheral device for down- 
loading firmware have been shown and described which 
have many desirable attributes and advantages. The method 
and peripheral device eliminate the need for the fail-safe 
data image of the download file to be executed during the 
download process before becoming effective. As a result, the 
switching mode of the non-volatile memory is no longer 
necessary, resulting in a more reliable, flexible and faster 
method. The present invention allows for the saving of the 
download file into the non-volatile memory while using only 
RAM for executions. 

While various embodiments of the present invention have 
been shown and described, it should be understood that other 
modifications, substitutions and alternatives are apparent to 
one of ordinary skill in the art. Such modifications, substi- 
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tutions and alternatives can be made without departing from 
the spirit and scope of the invention, which should be 
determined from the appended claims. 

Various features of the invention are set forth in the 
appended claims. 5 

What is claimed is: 

1. A method for downloading firmware responsive to a 
request by an operatively connected client computer from a 
connected host or a source to a peripheral device of the type 
which has a non -volatile memory, the peripheral device 10 
being adapted to download the firmware comprising the 
operating instructions and data into the non-volatile memory 
having at least one backup image partition for storing basic 
configuration and utility operations relating to the firmware 
and at least one code image partition for storing the 15 
firmware, the method comprising the steps of: 

receiving a download file for the requested firmware from 

the client computer; 
saving a specific data image of said file into one of the 2Q 

image partitions designated by said data image; 
performing an error check on said data image saved in the 

designated image partition; 
initiating a termination process if an error is found; and, 
repeating the above steps of the process for the next data 25 

image of said file if no error is found. 

2. The method according to claim 1 further comprises the 
step of initiating said termination process once all the data 
images for said file have been received for each designated 
image partition. 30 

3. The method according to claim 2 wherein said step of 
ending the process further comprises the steps of: 

sending a download -success message to the client com- 
puter; 

shutting down the peripheral device; and, 
restarting the peripheral device to execute said down- 
loaded firmware. 

4. The method according to claim 1 wherein said specific 
data image is determined by said file. 4 q 

5. The method according to claim 1 wherein said specific 
data image is a backup image of a basic configuration and 
utility operations of the firmware. 

6. The method according to claim 5 wherein said backup 
image is used for restoring the download process using the 45 
information of the basic configuration and utility operations 

of the firmware. 

7. The method according to claim 5 wherein said backup 
image is the first data image for downloading. 

8. The method according to claim 1 wherein said specific 50 
data image is a code image of the firmware. 

9. The method according to claim 1 wherein prior to said 
step of saving a specific data image, further comprising the 
steps of: 

checking said file for an acceptable format; 55 
receiving said file if the format is acceptable; and, 
initiating said termination process if the format is unac- 
ceptable. 
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10. The method according to claim 9 wherein said step of 
checking said file further comprises the step of reading the 
first few bytes of said incoming file. 

11. The method according to claim 9 wherein said step of 
initiating said termination process further comprises the step 
of sending an error message to the client. 

12. The method according to claim 1 wherein said step of 
saving a specific data image further comprises the steps of: 

receiving said data image from the client; and, 

storing said data image in said designated image partition. 

13. The method according to claim 1 wherein said step of 
performing an error-check further comprises the step of 
executing a cyclic redundancy code check for said data 
image. 

14. The method according to claim 1 wherein said step of 
initiating said termination process further comprises the step 
of sending an error message to the client. 

15. The method according to claim 1 further comprises 
the step of executing the data images from random access 
memory once all the date images for said file have been 
received for each designated image partition. 

16. The method according to claim 1 wherein the code 
image is downloaded without executing the backup image. 

17. A peripheral device for downloading firmware from a 
connected host or a source to a peripheral device that has 
been requested by an operatively connected client computer, 
the peripheral device having a non-volatile memory with at 
least one backup image partition for storing basic configu- 
ration and utility operations relating to the firmware and at 
least one code image partition for storing the firmware, said 
peripheral device comprising: 

means for receiving a file for the requested firmware from 

the client computer; 
means for saving a specific data image of said file into one 

of the code image partitions designated by said data 

image; 

means for performing an error check on said data image 
saved in the designated image partition; 

means for initiating a termination process if an error is 
found; and, 

means for repeating the process for the next data image of 
said file if no error is found. 

18. A computer program product comprising a computer 
readable code stored on a computer readable medium that, 
when executed, the computer program product causes a 
computer to: 

receive a download file for the requested firmware from 

the client computer; 
save a specific data image of said file into one of the image 

partitions designated by said data image; 
perform an error check on said data image saved in the 

designated image partition; 
initiate a termination process if an error is found; and, 
repeat the above steps of the process for the next data 

image of said file if no error is found. 

* * * * * 
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[57] ABSTRACT 

Method and apparatus for remotely altering programmable 
firmware stored in a PROM disposed on a target interactive 
network board having a local area network interface com- 
prises activating a local area network communication pro- 
gram. The communication program operates to broadcast an 
inquiry through the local area network for the designated 
interactive network board, to receive location information of 
the designated board in response to the broadcast inquiry, 
and to establish communication with the designated board. 
A ROM firmware image is downloaded into a RAM on the 
designated board, preferably through the local area network 
interface. A verifying step verifies that the ROM firmware 
image stored in RAM is valid, and the PROM is controlled 
to erase memory locations, to transfer preservable data from 
the PROM into predetermined locations within the ROM 
firmware image stored in RAM, and to load into the PROM 
the ROM firmware image from the RAM. After completing 
the flash operation, the designated board may be re-initial- 
ized to execute instructions from the firmware image stored 
in the PROM. 

23 Claims, 31 Drawing Sheets 
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METHOD AND APPARATUS FOR 
REMOTELY ALTERING PROGRAMMABLE 
FIRMWARE STORED IN AN INTERACTIVE 
NETWORK BOARD COUPLED TO A 
NETWORK PERIPHERAL 



BACKGROUND OF THE INVENTION 

1 . Field of the Invention 10 
The present invention relates generally to a circuit board 

which is coupled to a local area network peripheral (e.g. a 
printer) and which allows the peripheral to be an intelligent, 
interactive network member eliminating the necessity of 
dedicating a personal computer to manage the peripheral. 15 
More particularly, the present invention relates to a method 
and apparatus for remotely altering programmable firmware 
stored in an electronically erasable read-only memory 
(EPROM) on an interactive network board coupled to a 
peripheral device. 20 

2. Related Art 

Local Area Networks ("LANs") are known for coupling 
together a plurality of personal computers with peripheral 
devices such as printers, copiers, etc., to provide for 
enhanced communication and shared resources. Heretofore, 25 
peripherals such as printers coupled to a LAN were rather 
unintelligent, merely accepting information from the LAN 
and printing such information on a hard copy. Moreover, 
such printers usually required a host personal computer 
("PC") to effectively manage the flow of data to the printer, 
i.e., to act as a "server" for the printer. This almost always 
required that the host PC be dedicated solely to the printer 
server task. 

A number of products have recently appeared which 35 
ostensibly eliminate the need for such a dedicated PC by 
incorporating hardware and software into a circuit board 
which may be coupled into the peripheral in order to perform 
limited server functions. For example, ASP Computer Prod- 
ucts, Inc. provides a device known as "JetLAN/P" which 40 
acts as a stand-alone print server for Novell networks. The 
JelLAN/P® device couples to a LAN using a 1 0Base-2 thin 
coaxial cable or a lOBase-T twisted-pair cable. However, the 
JetLAN/P® couples to the printer only through the printer's 
parallel port. Thus, while print information can be sent to the 45 
printer, the amount of printer status information which can 
be returned from the printer is severely restricted. For 
example, such a device may obtain "off-line" and "out of 
paper" status from the printer, but little else. Such a device 
does very little toward making the printer a truly intelligent, 5Q 
responsive member of the network. 

Other known devices for coupling a printer to a LAN 
include the Hewlett-Packard Jet Direct® C2071A/B and 
C2059A, the Extended Systems EtherFlex®, the Intel Net- 
Port® and NetPort II®, the Castelle LANPress® and Jet- 55 
Press®, and the MiLAN FastPort®. However, all of these 
devices suffer from the same disadvantages as the ASP 
JetLAN in that they do not allow the printer to transmit 
sufficient amounts of data to the LAN to enable the printer 
to be an effective and intelligent member of the network. go 

Conventionally, a manufacturer formats and stores 
executable programs into programmable memories within 
computers and peripheral devices therefor. These executable 
programs generally are unalterable by the customer. There- 
fore, in the case the device requires an updated version of an 65 
executable program or if it is determined that the executable 
file docs not operate properly and the device requires 



servicing for the program, the executable program within the 
computer or the peripheral device must be altered either at 
the site of manufacture or at the site of the customer by a 
manufacturer's representative in order to have this function 
performed. For example, conventional printers store execut- 
able programs in ROM. These executable programs, which 
affect the manner in which an image is to be formed, are 
unalterable by the customer. Thus, if it is determined, after 
the product has been shipped to the customer, that there is a 
problem in the executable software, the manufacturer either 
has to recall the printer or must send a service representative 
out to the location of the printer at which point either an 
update of the software program or a new pre-programmed 
chip is installed. 

Heretofore, it has not been possible to remotely alter the 
executable files within a network peripheral device through 
a local area network from a remote LAN device. That is, a 
computer or a peripheral device could not be accessed 
through the LAN in order to alter or add additional execut- 
able files, and in addition, to receive remote commands 
through the LAN to execute the altered executable files or 
newly added files. Consequently, software updates and 
added executable files must be performed by the manufac- 
turer or at the customer's site by a service representative 
which is not only untimely, but expensive. 



SUMMARY OF THE INVENTION 

The present invention overcomes the drawbacks noted 
above by providing structure and function on a circuit board 
coupled to a peripheral which will permit the peripheral to 
be a responsive, intelligent member of a network. 

In one aspect of the present invention, a method for 
remotely altering programmable firmware stored in an inter- 
active network board is provided whereby firmware can be 
remotely altered by either revising or adding additional 
executable files stored in a PROM by downloading either an 
entire ROM firmware image or a portion of a ROM firmware 
image from a remote LAN device to the PROM on the 
interactive board. According to this aspect of the invention, 
a method for remotely altering programmable firmware 
stored in a designated interactive network board having a 
local area network interface comprises the step of activating 
a local area network communication program. The commu- 
nication program operates to broadcast an inquiry through 
the local area network for the designated interactive network 
board, to receive location information of the designated 
board in response to the broadcast inquiry, and to establish 
communication with the designated interactive network 
board. A ROM firmware image is downloaded into a RAM 
on the designated interactive board through the local area 
network interface. A verifying step verifies that the ROM 
firmware image stored in RAM is valid. The PROM is 
controlled to transfer preservable data from PROM into 
predetermined locations within the ROM firmware image 
stored in RAM, to electronically erase all erasable locations 
in the PROM, and to flash into the PROM the ROM 
firmware image from the RAM. After completing the flash 
operation, the interactive network board is re-initialized and 
receives instructions from the firmware image stored in 
PROM. 

In a related aspect, the invention provides an apparatus for 
remotely altering programmable firmware stored in a des- 
ignated interactive network board having a LAN interface 
which comprises local area network communicating means 
for broadcasting an inquiry through the local area network 
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for the designated interactive network board, for receiving 
location information of the designated board in response to 
the broadcast inquiry, and for establishing communication 
with the designated board. A RAM, resident on the desig- 
nated board, stores process steps. A PROM stores a ROM 5 
firmware image which contains process steps, and stores a 
designated identifier code. Comparing means compares a 
checksum of the ROM firmware stored in RAM with a 
checksum packet received from the LAN. Control means 
controls the PROM to preserve predesignated data by stor- 10 
ing that data within the ROM firmware image in RAM, to 
electronically erase storage locations of the PROM in accor- 
dance with the process steps stored in RAM, and to control 
the loading of the ROM firmware image from RAM into the 
PROM. 15 



BRIEF DESCRIPTION OF THE DRAWINGS 

The above-noted advantages and features of the present 
invention will become more readily apparent from the 20 
following detailed description of the preferred embodiments 
when taken in conjunction with the Drawings in which: 

FIG. 1 is a block diagram of a Local Area Network 
according to the present invention; 25 

FIG. 2 is a block diagram of a plurality of Local Area 
Networks coupled together, 

FIG. 3 is a block diagram showing the Network Expan- 
sion Board according to the present invention coupled 
between the Local Area Network and the printer; 30 

FIG. 4 is a block diagram of the Network Expansion 
Board according to the present invention; 

FIGS. 5 A, 5B and 5C comprise a top-level flowchart 
showing the basic functions of the Network Expansion 
Board according to the present invention; 

FIG. 6 is a diagram showing the sequence in which 
software modules are loaded from the Network Expansion 
Board ROM to RAM; 

FIG. 7 is a block diagram showing hardware and software 40 
interfaces between the LAN and the Network Expansion 
Board; 

FIG. 8 is a flowchart showing how the EPROM firmware 
is configured for placing the Network Expansion Board in an 
operational mode; 45 

FIG. 9 is a chart showing the physical construction of 
different frame packets used on Ethernet; 

FIG. 10 is a flowchart showing the operation of a PRES- 
CAN software module; 

FIG. 11 is a chart showing that the PRESCAN module 
may be used with other software protocols; 

FIG. 12 is a chart for explaining the software structure of 
the SAPSERVER program; 

FIG. 13 is a flowchart showing the operation of SAPS- 55 
ERVER; 

FIG. 14 is a flowchart showing the operation of a CPINIT 
program; 

FIG. 15 is a flowchart showing the operation of a 
CPCONSOL program; 

FIGS. 16A and 16B comprise a flowchart showing the 
operation of CPSOCKET program; 

FIGS. 17A and 17B comprise a flowchart showing the 
automatic logging of peripheral statistics; 65 

FIG. 18 is a flowchart showing how multi-tasking pro- 
cessing is performed; 
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FIG. 19 is a flowchart showing how to place the printer in 
a safe, default configuration; 

FIG. 20 is a flowchart showing the downloading of 
executable files to the Network Expansion Board from the 
local area network; 

FIG. 21 is a flowchart showing the loading of indepen- 
dently-executable modules in the EPROM of the Network 
Expansion Board; 

FIG. 22 is a block diagram showing Network Expansion 
Board EPROM flash protection circuitry; 

FIG. 23 is a flowchart showing the operation of the 
circuitry of FIG. 22; 

FIG. 24 is a flowchart showing the operation of remotely 
loading firmware in the Network Expansion Board EPROM; 

FIG. 25 is a block diagram showing a hardware configu- 
ration for testing the Network Expansion Board; and 

FIGS. 26A and 26B comprise a flowchart showing a 
method of testing the Network Expansion Board using the 
test configuration of FIG. 25. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

In its general aspects, the present invention provides 
hardware and software solutions for making a network 
peripheral, such as a printer, an interactive network member 
capable not only of receiving and processing data received 
from the network, but of transmitting to the network sig- 
nificant amounts of data such as detailed status information, 
operational parameters, and even data input to the peripheral 
through other modalities such as scanning, facsimile recep- 
tion, etc. By integrating such hardware and software with the 
peripheral, it is possible to eliminate the requirement for 
dedicating a personal computer to the peripheral to act as a 
peripheral server. 
1. ARCHITECTURE 

FIG. 1 is a block diagram showing the present invention 
incorporated into a Network Expansion Board ("NEB") 2 
coupled to a printer 4 which has an open architecture (to be 
discussed below). The NEB 2 is coupled to the LAN bus 6 
through a LAN interface 8, for example, Ethernet interfaces 
10Base-2, lOBase-T, or lOBase-5, respectively, with a Coax 
connector, an RJ45 connector, or a DB15 connector (AUI). 
Also coupled to the LAN 6 may be such network members 
as PC 10, PC 12, PC 14 (which in this case acts as the 
network administrator if the administrator has logged in at 
that PC; to be discussed below), and a printer 16 (with 
embedded QSERVER functionality; also to be discussed 
below). Other LAN members may include PC 18 (acting as 
a print server, to be discussed below) with attached printer 
20, PC 22 (acting as an RPRINTER; to be discussed below) 
with attached printer 24, and printer 26 which is coupled to 
the LAN 6 through a NetPort device 28 (discussed in the 
Background of the Invention above). A file server 30 is 
coupled to the LAN 6 and serves as a "library" for files to 
be transmitted and processed on the LAN. The file server 30 
may have attached printers 32 and 34. 

In more detail, the network depicted in FIG. 1 may utilize 
any network software such as Novell or Unix software in 
order to effect communication among the various network 
members. The present embodiments will be described with 
respect to a LAN utilizing Novell NetWare® software (to be 
discussed in greater detail in section 3a below) although any 
network software may be used. A detailed description of this 
software package may be found in the publications "Net- 
Ware® User's Guide" and the "NetWare® Supervisor's 
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Guide" by M&T Books, copyrighted 1990, incorporated 
herein by reference. See also the "NetWare® Print Server" 
by Novell, March 1991 edition, Novell Part No. 100- 
000892-001. Briefly, the file server 30 acts as a file manager, 
receiving, storing, queuing, caching, and transmitting files of 5 
data between LAN members. For example, data files created 
respectively at the PCs 10 and 12 may be routed to the file 
server 30 which may order those data files and then transfer 
the ordered data files to a printer 24 upon command from a 
print server in PC 18. The file server 30 may include or may 
be coupled to a large capacity storage member such as a 10 
Gigabyte hard disk subsystem. Furthermore, the printers 32 
and 34 may be coupled to the file server 30 to provide 
additional printing stations, if desired. 

While personal computer equipment is illustrated in FIG. 
1, other computer equipment may also be included, as 15 
appropriate to the network software being executed. For 
example, Unix workstations may be included in the network 
when Unix software is used, and those workstations may be 
used in conjunction with the illustrated PC's under appro- 
priate circumstances. 20 

PCs 10 and 12 may each comprise a standard work station 
PC capable of generating data files, transmitting them onto 
the LAN, receiving files from the LAN, and displaying 
and/or processing such files at the work station. The PCs 10 
and 12, however, are not capable of exercising control over 25 
LAN peripherals (unless the network administrator is logged 
into that PC). 

A PC capable of exerting limited control over LAN 
peripherals is PC 22 which includes an embedded 
RPR1NTER program. The RPRINTER program is a MS- 30 
DOS Terminate and Stay Resident ('TSR") program which 
runs on a work station to allow users to share the printer 24 
connected to the work station. RPRINTER is a relatively 
unintelligent program that does not have the ability to search 
printer queues for work. RPRINTER gets its work from a 35 
PSERVER (to be discussed below) that is running elsewhere 
in the network. Because they communicate with the attached 
printer over the printer's parallel port, RPRINTERs are able 
to obtain only limited status and to return that status infor- 
mation to the responsible PSERVER over the LAN 6. From 40 
a control standpoint, an RPRINTER allows stopping of a 
print job and little more. Some printers include RPRINTER 
features by offering internal or external circuit boards that 
provide the same limited features of the RPRINTER TSR 
program running in a personal computer. AS 

Another network entity capable of exercising limited 
control over LAN peripherals is a printer 16 with attached 
circuit board 36 having an embedded QSERVER program. 
Here, the QSERVER program runs inside an HP LaserJet 
ID® SI printer, and has the capability of searching the file 50 
server 30 print queues for eligible print files. The QSERV- 
ER' s search queues cannot be dynamically altered nor does 
the QSERVER respond to any form of status inquiry. The 
benefit of the QSERVER is its ability to autonomously 
search for work. The QSERVER does not require a 55 
PSERVER running elsewhere in the system to feed it work. 
Since the QSERVER does not have a corresponding 
PSERVER and it does not itself have any status and control 
capabilities, it offers less control than even the RPRINTER. 
A QSERVER also differs from a PSERVER in that it has 60 
extremely limited notification features and cannot print 
banners at the beginning of each print job. 

Another network member having a QSERVER capability 
is printer 26 which is coupled to the LAN 6 through an 
external NetPort device 28. 65 

Other peripheral server programs may be executed to 
service various peripherals, such as scanners, copiers, fac- 
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similes etc., and servers may also be provided based on 
network software protocol such as a Unix-compatible Line 
Printer Remote server ("LPR"). 

A LAN member capable of exercising significant control 
over LAN peripherals is the PC 18 having a PSERVER 
program embedded therein. PSERVER has the ability to 
service multiple user-defined print queues, perform dynamic 
search queue modification, and provide defined notification 
procedures for exception (failure) conditions and status and 
control capabilities. PSERVER is provided in several forms. 
PSERVER.EXE is a program that runs dedicated on a work 
station and controls both local and remote printers. The local 
printers can be connected to either serial or parallel ports, 
and the remote printers are printers running elsewhere in the 
system. Two other forms of the PSERVER program are the 
PSERVER. VAP and the PSERVER.NLM. These are 
PSERVER versions that run on the file server 30 itself. The 
.VAP version is for NetWare® 286, and the .NLM version is 
for NetWare® 386. While the PSERVER provides much 
more capability than the RPRINTER and QSERVER, one of 
its drawbacks is that the .EXE version requires a dedicated 
personal computer. 

A dedicated personal computer running PSERVER.EXE 
can control as many as 16 local/remote printers and can 
request print information from many file server queues. 
However, there are several drawbacks to relying on 
PSERVER to control network printing services. The first 
drawback is that multiple printer streams must all be fun- 
nelled through a single network node and personal computer 
processor. This can become a bottleneck. The second draw- 
back is that for the most efficient operation, the printers 
should be connected to the computer locally, as with the 
printer 20. This can be an inconvenience for users since it 
requires the printers to be clustered around PC 18. The third 
drawback is that if the controlled printers are remote as in 
the case of printer 24 which is serviced by RPRINTER, then 
the print data must make the trip from the file server 30 to 
the PSERVER PC 18 and then be retransmitted to the printer 
running RPRINTER. This is inefficient. 

The fourth drawback is the limited amount of printer 
status and control information offered through PSERVER. It 
has already been stated that APRINTER does not allow for 
much more than rudimentary status such as "out of paper" 
and "off line". PSERVER itself for locally and remotely 
connected printers does not offer much more than this 
because it was designed with consideration of the limitations 
of the personal computer parallel port. The PSERVER 
program also allows for its own status and control. 

The Network Expansion Board 2 installed in the printer 4 
provides many advantages and enhanced flexibility over the 
network peripheral control entities discussed above. In par- 
ticular, the NEB -embedded controller offers RPRINTER, 
PSERVER and LPR (Line Printer Remote) functionality 
(through C RPRINTER, CPSERVER and CLPR programs to 
be discussed in section 3d below). There is an initialization 
program named CPINIT (to be discussed in section 4h 
below) which allows the network administrator's PC 14 
complete control over the configuration of NEB features. 
Due to its embedded nature and the open architecture of 
printer 4, the NEB will have the ability to offer a wide 
variety of status and control features to the network. That is, 
verbose amounts of status information may be provided 
from the printer 4 to the LAN 6, and a great deal of control 
information may be provided from the LAN 6 to the printer 
4 (for example, exercising printer front panel functions from 
the PC 14). 

To access the extended amount of information available in 
the NEB, a program called CPCONSOL is resident in the 
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network administrator's PC 14 and allows the system 
administrator to view all of the printer information which is 
exported from the printer 4 by the NEB 2, The printer 
information is available even if the RPRINTER functional 
configuration (CRPRINTER) of the NEB 2 is selected. The 5 
PSERVER functional configuration (CPSERVER) of the 
NEB 2 will control the printer 4 that contains the board. This 
option will have all of the standard PSERVER queue search 
capabilities as well as the notify and status features. All of 
these features can be dynamically controlled from a remote 10 
work station. The NEB environment and its ability to export 
extended status and control information from the printer 4 
makes the combination of the NEB 2 and the printer 4 much 
more powerful than the standard RPRINTER, QSERVER, 
or PSERVER print methodologies currently available. 15 

The CPCONSOL program (to be discussed in greater 
detail in section 4i below) provided in the network admin- 
istrator's PC 14 is capable of interfacing with the NEB 2 
(and other network members) to perform such functions as 
displaying current information for a selected network device 20 
(interface information, control information, font informa- 
tion, layout information, quality and common environment 
information, duplex information, and miscellaneous infor- 
mation). CPCONSOL is also capable of setting or modifying 
the safe (default) condition of a network device. CPCON- 25 
SOL may also activate or deactivate applications of the NEB 
2 such as CPSERVER or CRPRINTER (to be discussed 
below, but generally similar to the PSERVER and 
RPRINTER software packages discussed above). Further- 
more, the CPCONSOL enables the PC 14 to display a log 30 
file, clear the log file, or write the log file to memory such 
as a local or a file system disk. CPCONSOL can also display 
such printer-related information on PC 14 as the number of 
jobs, the number of pages per job, the number of pages per 
minute, the time per job, the number of total pages per day, 35 
the number of total jobs per day, and the number of days. 
The CPCONSOL program is also capable of displaying on 
the PC 14 such network-related information as media related 
and non-media related information, and of clearing such 
network statistics. 40 

The CPINIT program (to be discussed in greater detail in 
section 4h below) resident in the network adrninistrator's PC 
14 can set up application information print services such as 
CPSERVER and CRPRINTER and configure those appli- 
cations. CPINIT is also capable of setting and/or displaying 45 
device information such as time/date/time zone, buffer size, 
disk size, logging flag, log limit, and a safe (default) 
environment flag. CPINIT can also restore default service 
headings, reset the NEB 2, reboot the NEB 2, command a 
font download, command an emulation download, display a 50 
NEB power-on-self-test ("POST') error, display the NEB 2 
firmware level, display the current log file size, etc. 

By providing the NEB 2 with PSERVER and RPRINTER 
capabilities, the present invention achieves, with a single 
circuit board, enhanced functionality for the printer 4 with 55 
respect to the LAN 6. Therefore, the printer 4 is a true 
' 'networked' ' printer and not just a printer connected to a 
network. 

While the present invention offers unique advantages on 
the LAN 6, these advantages are also realized when the LAN 60 
6 is coupled to one or more other LANs in a Wide Area 
Network ("WANT). FIG. 2 depicts such a WAN which 
includes a first LAN 41 including a server SI 40, PCs 42, 
44, and 46, and a printer 48. The server SI 40 is coupled to 
a backbone 50 over a bus 52. The backbone 50 is nothing 65 
more than an electrical connection between a plurality of 
buses. Also connected to the WAN is a second LAN 61 
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comprising server S2 60, PC's 62, 64, and 66, and a printer 
68. Server S2 60 is coupled to backbone 50 over bus 54. 

The WAN may also include a remote LAN 71 comprising 
server S3 70, PC's 72, 74 and 76 and a printer 78. Since the 
LAN 71 is remote from the remainder of the system, it is 
coupled to backbone 50 through a bus 56, a transponder 
(which may include a modem) 58, and a communication line 
59. 

In such a WAN, assume that PC 42 is a PSERVER 
requesting the use of printer 78. If the printer 78 is equipped 
with a NEB according to the present invention, a direct 
communication link can be established between the PC 42 
and the printer 78 whereby job information can be sent to 
printer 78, and status and control information can be sent 
from printer 78 to the LAN 41. Therefore, the NEB accord- 
ing to the present invention achieves its enhanced function- 
ality even when installed in a peripheral coupled to a WAN. 

FIG. 3 is a block diagram depicting the connection of the 
NEB 2, according to the present invention, with the printer 
4 and the LAN 6. The NEB 2 is directly connected to the 
LAN 6 via LAN interface 101, and also to the printer 4 via 
a bi-directional interface, here a Small Computer System 
Interface ("SCSI") 100. The SCSI interface 100 is coupled 
to an SCSI bus 102 of the printer 4. 

The NEB can also service additional SCSI devices, such 
as other printers (RPRINTERs) or other peripherals, daisy- 
chained on the SCSI bus using standard SCSI connectivity 
protocol. Also, the NEB may be used to drive other periph- 
erals across the ELAN itself. 

The printer 4 is preferably an open-architecture printer 
including the SCSI bus 102 and SCSI interfaces 104 and 
106o Printer 4 also includes a processor 108 such as a 
REDUCED INSTRUCTION SET COMPUTER ("RISC") 
which communicates with a RAM Memory 110 and with a 
printing engine 112 which actually drives the printing 
mechanism. The RISC processor also communicates with 
NVRAM 111 for storing information which needs to be 
maintained between power cycles, such as user-defined 
information, and with ROM 113 from which RISC processor 
108 executes printer control. TTie printer 4 may also include 
a hard disk 114 capable of holding large amounts of data in 
a non-volatile way. Printer 4 also has a front panel display 
116, and a keyboard 115 for inputting control commands to 
the printer. 

Preferably, the printer 4 includes an open architecture 
which takes advantage of the bi-directional nature of the 
SCSI interface 100 to provide a great deal of status (and 
other) information from the printer 4 to the LAN 6 via the 
NEB, and also to allow fine control of the printer from a 
remote location. For example, such open architecture when 
used with the bi-directional SCSI interface permits most or 
all of the information on the front panel display 116 of 
printer 4 to be exported to a remote location, and also 
permits most or all of the control functions of the printer 
front panel keyboard 115 to be activated from the remote 
location. 

Briefly, the open-architecture printer 4 comprises four 
major subsystems: Communication; Job Pipe; Page Layout 
and Raster functions; and Systems Services. The Commu- 
nication subsystem handles the different communication 
devices and initiates the start of a job application. When the 
printer starts to receive data, the Communication subsystem 
sends the first part of the incoming data to each emulator for 
examination. The first emulator that can process the data 
becomes the Job Pipe driven The system then constructs a 
Job Pipe to process the data (data flows into one end of the 
pipe, and page images flow out of the other end). This Job 
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Pipe comprises many segments one of which is the Job Pipe 
driver. 

The Job Pipe subsystem has a Pipe driver segment (the 
application for an emulator) and input and output segments. 
The input and output pipe segments have at least two other 
segments: for input, source and source filter segments; and 
for output, an output filter and a data sink. The input segment 
of the Communication subsystem delivers the input data 
which can be supplemented by information from a file 
system. The Pipe driver processes input and supplemental 
data. It also generates imaging commands and page layout 
information that it sends to the output segment. The Pipe 
driver may store this information to the printer disk (if 
present). The output segment sends this data to the Page 
Layout and Raster subsystem. 15 

The Page Layout and Raster subsystem takes the imaging 
and page layout information and converts it to a raster image 
for the print engine 112. This section operates completely 
separately from Job Pipe. 

The System Services subsystem provides file system 20 
access, console access, font services, basic system services, 
and image generation services. Therefore, a printer 4 having 
such an open architecture will take full advantage of the 
intelligent, interactive NEB 2 to provide increased function- 
ality to the printer 4 and the entire network. 
2. HARDWARE 

FIG. 4 is a block diagram of the NEB 2 showing the major 
components thereof. The NEB 2 is coupled to the LAN 6 
through network connectors 202, 203, and 204. Preferably, 
the connector 202 is an RJ45 capable of accepting a lOBase- 
T connection. The connector 203 may comprise a DB15 
connector for accepting a 10Base-5 connection, while the 
connector 204 may be a simple Coax connector capable of 
accepting a 10Base-2 connection. All of the connectors 202, 
203, and 204 are coupled to a network controller 206 35 
(preferably an Ethernet Network Controller). However, the 
connector 204 is first coupled through a transceiver 208. 

Power is supplied to NEB 2 from a +5 V power source in 
printer 4 through the printer expansion port 226. The +5 V 
power is also provided to the power converters 210 and 212. 40 
The power converter 210 provides -9 V power to transceiver 
208, while the power converter 212 provides +12 V power 
for "flashing" (loading; to be discussed in section 4q below) 
the EPROM 222. Also, the network controller 206 is 
coupled to an 8 KB static RAM 214. 

The heart of the NEB 2 is a microprocessor 216, prefer- 
ably an NEC V53. The microprocessor 216 is coupled to a 
serial port 218, currently used for testing. Also coupled to 
the microprocessor 216 are a 512 KB dynamic RAM 220, a 
256 KB flash EPROM 222, an SCSI controller 224 (corre- 
sponding to SCSI interface 100 of FIG, 3) a printer expan- 
sion port 226, a diagnostics/failure LED 240, a 256 Byte 
non-volatile RAM 228, a control register 230, and a PROM 
232 which stores the Media Access Control ("MAC") 
address which is the unique name for every EtherNet board. 

The architecture of the NEB 2 provides an advantage in 
that it has unique support features for administration and 
management of large, multi-area networks. These support 
features include, for example, printer control and status 
monitoring from a remote location on the network, (i.e., 
from the network administrator's office), automatic manage- 
ment of printer configuration after each print job to provide 
a guaranteed initial environment for the next user, and logs 
of printer usage statistics accessible across the network for 
characterizing printer workload and scheduling toner car- 65 
tridge replacement A key parameter in the NEB design is 
the ability to access the primer control state from the NEB 
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2 through a bi-directional interface, here the SCSI interface 
100. This allows the printer console information to be 
exported to the NEB or to an external network node for the 
programming of many useful printing support functions. 

Table 1 below provides a description of the functions, 
implementation, and operational notes with respect to the 
major hardware elements of NEB 2. 



TABLE 1 


Function 


Implementation 


Notes 


Network Controller 


National DP 83902 


With DP8392 Coax 


(206) 




Transceiver 


Ethernet Interfaces: 


10Base-2 (202) 


Coax connector 




lOBase-T (204) 


RJ45 connector 




]0Base-5 (203) 


DB15 connector 








Embedded Proces- 


NEC V53 


16-bit/16Mhz MPU 


sor: 




with DMA, timers, 


(216) 




Interrupts 


EPROM (Flash) 


256K Bytes 


Network program 






rriAf* hnarA RTfY? 
CUUG, DUolU OIUO 
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diagnostics 


NVRAM 


256 Bytes 


Printer 


(220) 




Installation 






Configuration on 






Network 


DRAM 


512K Bytes 


Code execution and 


(220) 




data buffering for 






exp.port 


SRAM 


8K Bytes 


Buffering of 


(214) 




incoming Ethernet 






packets 


SCSI Controller 


NCR 53 CSX) A 


30-pin, internal 


(224) 




I/F configuration 






with power 


MAC Address and 


32 Bytes 


Stores, MAC address 


Hardware ID 




and Hardward ID 


PROM (232) 




information 


Board Size 


100 mm x 125 mm 


Type 2 EXP-I/F 






PCB, double-sided 






SMT 


Power 


5vdc, 710 ma 


DC converter on 






board for Ethernet 






+12vdc/-9vdc 



Preferably, the NEB 2 is installed inside the printer 4 in 
an expansion or options slot. The NEB 2 is thus an embed- 
ded network node with the processing and data storage 
features described above. 

The microprocessor 216 implements a data link layer of 
network packet transmission and reception. Network data 
transfer overhead is minimized through the use of a dedi- 
cated static RAM packet buffer 214 managed directly by the 
network controller 206. The microprocessor 216 accesses 
blocks of SRAM packet data and network messages through 
the network controller 206, and moves them into the large 
DRAM memory 220. 

Blocks of print image data and control information are 
assembled by the microprocessor 216 for transmission to the 
printer 4 by the SCSI controller 224 using the SCSI transfer 
protocol of the printer expansion port. Likewise, printer 
status information is transferred from printer 4 back to the 
NEB 2 in SCSI block format. The SCSI controller 224 
operates concurrently with the network controller 206 for 
increased data throughput for overall NEB performance. 

The microprocessor 216 is preferably an NEC V53 chip 
which is a fast, highly-integrated microprocessor with a 
16-bit Intel-compatible processor in support of Direct 
Memory Access ("DMA" ) t interrupt, timers and DRAM 
refresh control. Data bus structure on the NEB 2 is imple- 
mented 16-bits wide to take advantage of the 8-Bit/l 6-Bit 
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dynamic bus sizing during microprocessor I/O transfers. 
Control firmware and printing application software for the 
microprocessor 216 are stored on the NEB 2 in EPROM 
222. After power-on self-test, the firmware code is selec- 
tively moved to the higher-performance DRAM 220 for 5 
actual execution. Network and printer configuration param- 
eters are written into NVRAM 228 when the printer is first 
installed onto the network. Thus, NVRAM 228 allows the 
NEB software to recover the installation parameters after 
printer power has been cycled off and on. 
3. SOFTWARE 10 

Software for the LAN comprises a combination of net- 
work software, and NEB-customized software such as NEB- 
embedded software and software resident on the network 
administrator's PC. 

3a. Network Software 15 

In the present embodiment, NetWare® network software 
is used to manage interactions between nodes of a network 
such that the client work stations can share and receive 
services from server nodes such as disk file servers, database 
servers, print servers, etc. NetWare© itself is a combination 20 
of software modules running on these server nodes and on 
each work station node. At least one file server may be 
provided in a Novell network. NetWare® runs as the oper- 
ating system for the PC of the file server to provide basic 
network core services and utilities. File servers can connect 25 
to more than one LAN by using up to four network interface 
cards (preferably Ethernet or Token Ring connections). In 
these configurations, "bridging" or "backbone" services are 
provided between a plurality of LANs, as shown in FIG. 2, 
such that resources, including printers, can be shared "inter- 30 
net" i.e., from one LAN to another. 

On work stations, NetWare® runs in cooperation with the 
work station operating system (DOS or OS/2) as a Net- 
Ware® "shell" of control software. This shell has the effect 
of extending the services of the workstation operating sys- 35 
tern onto the network to make network resources appear 
local to the work station. 

Novell PSERVER software has the job of controlling a 
group of printers (up to sixteen) in order to service printing 
requests from network nodes. Requests are structured in a 40 
form of print queues that are held on the network file server 
using network queue management services. Queue entries 
contain a list of files to be printed. The files contain data to 
be printed such as tabs, formfeeds, and other Printer 
Description Language ("PDL") commands. Several queues 45 
can be serviced by a single PSERVER. 

Standard Novell servers are available in different versions 
depending on the type of network node they are to execute 
on. Print server programs can reside on the file server itself. 
A version of print server software may also be loaded on a 50 
stand-alone DOS station node to make that node a dedicated 
print server. 

By providing print server functionality (CPSERVER) to 
NEB 2 of the present invention, the NEB and attached 
printer will offer all the printing services of a standard 55 
Novell print server without the need for an attached PC. 

Printers themselves are considered to be either "local" or 
"remote". A local printer is one that is physically connected 
to the print server node. In the case of the NEB 2, the local 
printer is the printer housing the NEB. A remote printer is 60 
managed by RPRINTER programs running in the PCs they 
arc connected to. RPRINTERs receive print data from 
PRINTSERVERS running elsewhere on the LAN. The NEB 
2 of the present invention can be provided with RPRINTER 
functionality (CRPRINTER) to offer its printer as a network 65 
remote printer. In this mode, it is fully compatible with 
standard versions of Novell print servers. 



,604 

12 

Novell NetWare® provides a number of print utilities to 
configure and control file server or work station-based print 
servers and their attached printers. The Novell program 
PCONSOLE is a menu-driven utility that allows a user (the 
printer console operator) to create a new print server, con- 
figure up to sixteen local or remote print ports, create print 
queues, assign queues to printers, and start/stop printer and 
server operations. 
3b. NEB -Customized Software 

The NEB 2 is bundled with software modules that imple- 
ment the full range of printing services offered by Net- 
Ware®. This includes external NetWare®-compatible mod- 
ules that execute on work station nodes of the network in 
addition to internal NetWare®-compatible modules running 
on the NEB 2 inside the printer. The specific NetWare® 
compatible programs developed for use with the NEB 2 
(e.g., the customized CPSERVER and CRPRINTER pro- 
grams to be discussed below) are provided with the same 
general operational interfaces as standard printing modules 
from Novell so as to be familiar to Novell users and network 
administration personnel. The customized versions include 
functional extensions that make use of the open architecture 
of the printer 4 to enhance print service management across 
the network. 

Table 2 shows the functions, implementations, and opera- 
tional notes for the customized software developed for the 
NEB. 



TABLE 2 



Function 


Iraplementaiion 


Notes 


NEB-specific 


CPSERVER (92KB) 


Customized Print 


functions in NEB 




Server 


EPROM 


CRPRINTER (40KB) 


Customized Remote 






Printer 


NEB-to-Network 


CPSOCKET (30KB) 


Concurrent multi- 


communication in 




protocol operation 


NEB EPROM 






NEB Environment 


(15KB) 


Monitor, loader, 


in NEB EPROM 




POST, etc. 


Extensions to 


CPCONSOLEXE 


Remote Control & 


NetWare @ 


(180KB) 


Stats, Auto- 


PCONSOLE for 


CPINIT.EXE 


Reconfiguration, 


Primer 


(120KB) 


Print Job 


Control/Configur- 




Logs/Statistics 



alion in 
Administrator's 
PC 14 



3c. NEB-Embedded Software 

The software developed for the NEB 2 includes software 
embedded in the NEB and software loaded into the network 
administrator's PC 14. The NEB-embedded software pro- 
vides both the NetWare®-compatible node and NetWares- 
compatible print services directly inside the printer 4 with- 
out the overhead of a work station PC and its DOS operating 
system. The NEB-embedded software comprises a plurality 
of application modules (CPSERVER, CRPRINTER, etc.), 
real-time service modules, network protocol stacks, and a 
MONITOR program which performs application switching, 
process extension, device semaphores, and shares buffer- 
pool management. The functionality of the NEB is deter- 
mined by the types of application modules and the number 
of protocol stacks of network layered communication soft- 
ware that are configured into the NEB 2. Interaction between 
the printer 4 and the network is coordinated by the MONI- 
TOR program which responds to real-time events while 
allocating NEB processing time to each application module 
on a multi-tasking basis. 

The NEB software functions at two layers: a "run-time" 
or real-time layer; and a "soft-time" or applications layer. 
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The run-time layer is comprised of components of NEB 
software that respond to microprocessor interrupts. This 
layer services devices such as a timer, queued data transfer 
requests from the SCSI port, or LAN data through the 
protocol stack routine, and the CPSOCKET (to be discussed 
in section 4j below) communication mechanism. 

The soft-time layer is arbited and controlled by the 
MONITOR program (to be discussed in section 41 below) 
which gets control of the NEB microprocessor 216 after all 
real-time events have been serviced. A non-preemptive 
(cooperative multi-tasking) approach is used to divide the 
processor between the various application modules that are 
loaded such that no one application module can pre-empt 
other modules by capturing the microprocessor. 

The NEB EPROM 222 contains up to 256 KB of appli- 
cation module programs and NEB initialization code. At 
power-up or during a programmed reset, the NEB 2 executes 
a POST from the EPROM 222 before selectively transfer- 
ring its EPROM code to NEB DRAM 220. If the POST is 
successful, the NEB 2 will load its protocol stacks and 
application modules into DRAM, and begin execution of its 
application modules. 

In its basic configuration, the NEB 2 contains NetWare®- 
compatible application modules comprising embedded ver- 
sions of two configurations: the Customized Remote Printer 
("CRPRINTER"); and the Customized Print Server ("CPS- 
ERVER"). Preferably, the NEB acts in only one of these 
configurations at a time. Further, these application modules 
require that a network protocol stack be loaded and func- 
tioning within the NEB. 

When configured with RPRINTER functionality, the NEB 
operates its printer as a slave to an external print server using 
a CRPRINTER module. In this configuration, the NEB 
exports to the LAN only limited printer status information in 
emulation of what the standard Novell print server expects 
from a standard Novell RPRINTER. However, extended 
status information about the printer will still be available if 
the CPCONSOL utility (discussed above) is executed in the 
network administrator's PC 14. 

As mentioned above, the NEB 2 includes embedded 
software programs CPSERVER and CRPRINTER which 
enable the NEB to act with either PSERVER or RPRINTER 
functionality on the network. The customized NEB-embed- 
ded software which permits peripheral status and control 
information over the LAN is CPSOCKET (to be discussed 45 
in section 4j below). CPSOCKET runs on the NEB and 
monitors the LAN for communications addressed to both the 
NEB 2 and the attached printer 4. Further, CPSOCKET 
communicates with CPINIT and CPCONSOL when they are 
running. CPSOCKET will maintain a table of default set- 
tings for the device environment, download basic configu- 
ration information (fonts and emulations) at power-up, pro- 
vide device information, statistics, and log information for 
CPCONSOL displays, and provide reset, reboot, and down- 
load capabilities. CPSOCKET will also be responsible for 
the configuration of the NEB 2. Further, CPSOCKET will 
configure and activate applications on the NEB at the 
request of CPINIT. CPSOCKET also insures that the correct 
protocol stacks are available for each configured application. 
CPSOCKET will handle the settings of the NEB 2 and the 60 
printer variables at the request of both CPINIT and CPCON- 
SOL. Finally, the download facility (e.g. the network admin- 
istrator's PC 14) will contact CPSOCKET to carry out any 
firmware downloading, such as flashing EPROM 222, that is 
required. 

Upon initialization, programs such as CPINIT and 
CPCONSOL will issue a Service Advertising Protocol 
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("SAP") on the LAN looking for all network devices having 
the customized software of NEB 2. CPSOCKET will receive 
this broadcast signal and will respond. CPINIT or CPCON- 
SOL then establishes a special connection with CPSOCKET 
using a customized client socket CPSOCKET will then post 
multiple listens and will provide client service transactions 
such as NEB control, device information, basic configura- 
tion information, application information, statistics, and 
logging. For example, CPINIT can request that an applica- 
tion be configured, and CPCONSOL can request that an 
already-configured application be activated or deactivated. 
CPSOCKET will insure that the appropriate option (protocol 
stack) is available and configured for an application before 
allowing the application itself to be configured. Within the 
NEB, the CPSOCKET operational module is always acti- 
vated. 

Additional print service applications may be utilized after 
loading further application modules into the NEB, for 
example, UNIX print services and associated protocol 
implementation. 

3d. PC-Resident Customized Software 

To further enhance the functionality of the NEB 2, cus- 
tomized software is also provided to the network adminis- 
trator's PC 14. For example, a Customized PCONSOLE 
("CPCONSOL"; to be discussed in greater detail in section 
4i below) utility provides extensions to Novell's PCON- 
SOLE printer utility to enable access to the powerful control 
and monitoring features of the open-architecture printer 4. 
For example, the following are typical status control infor- 
mation available to the network from the printer through the 
use of CPCONSOL: (A) status and control information such 
as online/offline, no response, time/date/time zone, lan- 
guage, offsets, error skip settings, timer, buzzer enable, toner 
low, paper full, paper counter, count since last service, paper 
out, paper jam; (B) font information such as primary, sec- 
ondary, graphic set, scaling, rotation, elite; (C) layout infor- 
mation such as page orientation, line pitch, character pitch; 
(D) quality and common environment information such as 
number of copies, overlay, job complete, command mode, 
default paper size, current paper size; and (E) configuration 
information such as interface, buffer size, feeder select, 
duplex print, page stack order, etc. 

Furthermore, configuration data for the printer accessible 
to the network through the use of CPCONSOL includes: (A) 
network group information such as protocol type, the node 
name, the file server name, routing, POST error code, NEB 
firmware level, MAC address, server mode; and (B) printer 
group information such as safe (default) environment, font, 
disk present, disk size, initial environment, logging on/off, 
log file size, configured/nonconfigured, and net name. Addi- 
tionally, logs can be kept of print job flow, print engine 
usage, and network behavior. Examples of such usage and 
statistical log entries include: (A) network group informa- 
tion such as receive statistics, transmit statistics, and non- 
media related information; (B) job entry information such as 
date/time/time zone, log-in (user's name), job name, pages, 
copy count, and print status; (C) initialization entry infor- 
mation; (D) error condition entry information; (E) clear log 
entry information; and (F) printer group information such as 
the number of jobs, pages/job, pages/minute, time/job, total 
pages/day, total jobs/day, number of days and total resets. 

CPCONSOL is a menu-driven DOS executable program 
whose function is to provide extensions to the Novell 
PCONSOLE printer utility. The CPCONSOL extension 
enables access to the additional control and monitoring 
features of the open-architecture printer 4. These features 
will enhance print service management across the network 
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by allowing the network administrator's PC 14 to control 
and maintain the printer from a remote location. In summary, 
CPCONSOL is the utility that exports printer control fea- 
tures to the network administrator, allows reconfiguration of 
the safe (default) environment, and allows the network 5 
administrator to view network and printer status, job statis- 
tics, and a log of the previously-processed jobs and error 
conditions. CPCONSOL gathers the requested information 
by communicating with the NEB -embedded software pro- 
gram module CPSOCKET. 10 

Another customized software program resident on the 
network administrator's PC 14 is Customized Peripheral 
Initializer ("CPIN1T , ; to be discussed in section 4h below) 
which is also a menu-driven DOS executable program. The 
function of the program is to configure, reconfigure, and is 
initialize the printer 4 attached to the NEB 2. 

The CPINIT module will configure the NEB to act as a 
print server with one attached printer and specifies its 
primary file server by which the NEB will determine which 
queues to service. CPINIT is the program that supervises all 20 
like-customized devices on the LAN (e.g. other NEBs 
installed in other open-architecture printers). CPINIT 
accomplishes this task by communicating over the network 
with other NEBs that reside within open-architecture periph- 
eral devices. CPINIT is used to configure each NEB with the 25 
appropriate basic configuration information such as config- 
uring the NEB as CPSERVER or CRPRINTER. The basic 
configuration information comprises NEB environment set- 
tings (including which print server applications are active), 
as well as device environment options (e.g. a list of fonts and 30 
emulations to download printer initialization time), and 
device default settings (such as the internal device time/ 
date/time zone, buffer size, disk and logging information, 
and printer name). The CPINIT program also displays status 
information about the NEB (such as the firmware level 35 
loaded in the NEB and reports latent POST errors). 

The CPINIT program will broadcast over the network to 
see which other customized devices are available on the 
LAN. The NEBs attached to such other customized devices 
will respond with their identification numbers, their device 40 
types, and their configuration states. CPINIT will construct 
a list of these NEBs and devices that will be presented to the 
network administrator to allow their configuration or recon- 
figuration. 

A DOWNLOADER program may also be loaded into the 45 
network administrator's PC 14 to download executable files 
to the NEB across the network (to be discussed in greater 
detail in section 4n below). 

Another customized program which may run on the 
network administrator's PC 14 is CPFLASH which may be 50 
used to remotely flash new firmware into EPROM 222, as 
will be discussed in greater detail in section 4q below. 
4. OPERATION 

At first, an overview discussion of the NEB structure and 
functions will be provided with respect to the flowchart of 55 
FIGS, 5A, 5B and SC. Thereafter, more detailed descriptions 
of various aspects of the NEB hardware and software will be 
provided with respect to sections 4a to 4q. 

The present invention takes advantage of the bi-direc- 
tional nature of the communication between the printer and 60 
the NEB, and the NEB's ability to process information on a 
multi-tasking basis. That is, the bi-directional SCSI bus can 
transmit large quantities of data both to and from the printer, 
enabling the NEB to receive large quantities of specific 
status data from the printer or even data input from the 65 
peripheral (such as image data input from a scanner). The 
NEB microprocessor processes information on a multi- 
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tasking basis (sequential but shared) effectively parallel 
processing information received from the network and infor- 
mation received from the printer. This multi-tasking pro- 
cessing insures that the NEB is responsive to both the 
network and the printer on a near real-time basis. 

FIGS. 5A, SB, and 5C comprise a top-level flowchart 
depicting a notional sequence of events which may occur 
when the NEB and its associated software is installed in a 
printer coupled to a local area network. Overall, the printer 
renders print information and is coupled to the NEB through 
a bi-directional SCSI interface. The printer may also have a 
parallel port and/or a serial port for receiving print infor- 
mation from other sources. The NEB is connected to the 
printer via the bi-directional SCSI interface, the board 
receiving printer information from the local area network. 
The board sends print jobs and printer status inquiries to the 
printer over the SCSI interface, receives printer status from 
the printer over the SCSI interface, and reports printer status 
over the network. 

Where the NEB is coupled to a data generating device 
such as a scanner, the board is connected to the scanner 
through the bi-directional SCSI interface and is coupled to 
the network via the LAN interface. The board receives status 
request information from the network and will pass this 
information to the scanner over the bi-directional interface. 
The board will also receive the data generated by the scanner 
over the bi-directional interface, and will pass that data onto 
the network over the LAN interface. 

Illustrating a sequence of events which may occur when 
the NEB is installed in a printer, FIG. 5 A begins when power 
is applied to the NEB at Step SI. At Step S2, the NEB 
executes a power-on-self-test ("POST') from EPROM 220. 
At Step S3, if the POST is successfully completed, the 
process moves to Step S5 where the NEB EPROM 222 
operational code reads the network and printer configuration 
code from NVRAM 228. If the POST is not successfully 
accomplished at Step S3, a failure indication is logged at 
Step S4 and this information may be transmitted to the 
network over the LAN interface. An LED failure/diagnostics 
light on the NEB or printer may also be activated. 

After the network and configuration code have been read 
from NVRAM 228, the procedure advances to Step S6 
where the NEB EPROM operational code reads selected 
configuration modules, protocol stacks, housekeeping mod- 
ules, etc., (e.g., the MONITOR multi-tasking module, 
CPSOCKET, CPSERVER, etc.) from EPROM 222, and 
downloads the selected modules to DRAM 220. In Step S6, 
a configuration is selected (in accordance with the configu- 
ration set by CPINIT) which defines an operational mode 
(e.g. CPSERVER or CRPRINTER) of the interactive net- 
work board. As will be discussed in greater detail in section 
4d below, a binary configuration code is sent over the LAN 
and stored in NVRAM 228. After the NEB is booted up, the 
configuration code is read from NVRAM using ROM- 
resident power-up process steps. Using the ROM-resident 
process steps, ROM-resident executable modules are 
selected in accordance with the configuration code read from 
NVRAM. The modules are selected in bit- wise correspon- 
dence to the binary digits of the configuration code in 
NVRAM. The selected modules are then stored into DRAM 
and execution control for the modules is passed to DRAM 
whereupon the selected modules are executed. In this man- 
ner, multiple configurations can be defined and selectively 
changed. 

At Step S7, the EtherNet frame type of the information 
packets transmitted on the LAN is determined (as will be 
discussed in greater detail in section 4e below). That is, 
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EtherNct supports four different frame types: EtherNet 
802.3 ; EtherNet II; EtherNet 802.2; and EtherNet SNAP. To 
determine the EtherNet frame type, a pre-scan process 
("PRESCAN") determines what frame type is resident on 
the LAN (from any LAN broadcast data), and configures the 5 
appropriate NEB-resident protocol stack for that data. The 
pre-scan process strips away bytes of data from a received 
LAN packet until the bytes which indicate frame type are 
reached. Briefly, Step S7 provides the NEB with the capa- 
bility of processing LAN packets of different frame types by: 10 
receiving from the LAN a frame of data, pre-scanning the 
frame to determine the frame type, and processing, on the 
NEB, the identified frame, using an appropriate processing 
program. The pre-scanning operation includes the sub-steps 
of stripping a predetermined number of bytes from the head 15 
of the frame, processing the stripped frame to identify an 
identification code indicative of the frame type, and trans- 
mitting the identified frame to the processing program. 

At Step S8, a timer module which was downloaded in 
Step S6 finds the nearest LAN server and requests the 20 
current time. After receiving the current time, the process 
proceeds to Step S9 where it is determined whether it is 
midnight, i.e. whether the returned time indicates a new 
date. 

Steps S9 through S12 comprise a so-called "autologging" 25 
function which is carried out in the NEB by the CPSOCKET 
program in order to automatically and systematically pro- 
vide status information from the printer to the LAN 
(autologging will be discussed in greater detail in section 4k 
below). In Step S9, if midnight has not been reached the 30 
procedure advances to Step S13. However, once midnight is 
reached, the NEB microprocessor 216 transmits a request to 
the printer over the SCSI bus for the printer to return current 
status to the NEB. For example, the printer may return the 
cumulative number of pages printed to the NEB. In Step 35 
Sll, the NEB microprocessor 216 calculates printer statis- 
tics such as pages per job or pages per day, the NEB having 
kept track of the number of jobs sent to the printer and the 
date. At Step S12, the printer statistics are transferred to a 
non-volatile memory such as the printer's hard disk 114 or 40 
NVRAM HI, or the NEB's NVRAM 228. Alternatively, 
Steps S10, Sll, S12 may be performed before Step S9, so 
that statistics are stored every minute. 

Summarizing Steps S9 through S12, a method for logging 
system statistics of a printer connected via a bi-directional 45 
interface to an interactive network board for LAN commu- 
nication includes the steps of counting in the printer the 
number of pages printed, and counting on the board the 
number of jobs printed. The printer is interrogated daily over 
the bi-directional interface for the number of pages printed, 50 
and the board then calculates daily statistics using the 
number of pages, the number of jobs, and other status 
information. The daily statistics are then stored and may be 
accessed and remotely displayed using CPCONSOL from 
the network administrator's PC 14. An additional feature of 55 
the "autologging" function is that different levels of statistics 
may be logged. For example, at a basic level, only the . 
number of pages for each job may be logged. At more 
advanced levels, the number of pages per job plus a log of 
failure conditions may be logged; or the job start and end 60 
times may be logged in addition to the failure conditions and 
the number of pages per job. The logging level is set by 
CPINIT. 

In FIG. SB, at Step S13, the SAPSERVER program (to be 
discussed in greater detail in section 4g below) advertises 65 
the NEB as having both CPSERVER and CPSOCKET 
identities. Thus, the NEB and attached printer can function 
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in its twin roles of PSERVER and customized entity 
(CPSOCKET, i.e., similar to other LAN peripherals having 
a NEB installed therein). SAPSERVER is a NEB-resident 
TSR program that allows more than one server to advertise 
network services at the same time on the same node. Thus, 
CPSOCKET and CPSERVER both advertise their services 
through SAPSERVER and respond to inquiries from other 
network applications. Since each EtherNet board can have 
only one SAP socket number, SAPSERVER will function to 
advertise both NEB identities without confusion to the LAN. 

In summary, Step S13 is a method of identifying a single 
interactive network board as two network servers (e.g. 
CPSERVER and CPSOCKET) comprising the steps of 
transmitting to the network at a predetermined time interval 
a signal indicating that the board is a first type of network 
entity, the signal including an identification signal unique to 
the board; then, transmitting a second signal to the network 
at the predetermined time interval to indicate that the board 
is a second type of network entity, the second signal also 
including the same unique identification signal. Once a 
signal is received from the network requesting that the board 
perform functions of one of the types of network entities, 
direct communication is established between the board 
(acting as the requested type of network entity) and the 
network entity which generated the request. When the direct 
communication is established, the NEB will utilize a new 
unique identification signal. 

At Step S14, both the LAN and the SCSI interfaces are 
checked for data that is being directed to CPSOCKET (to be 
discussed in greater detail in section 4j below). The SCSI 
interface will typically have printer status data which is to be 
passed to the LAN in response to a previously-received 
request for status. CPSOCKET is the NEB-resident TSR 
program that responds to such requests for connection, 
requests for data download, or requests for services from 
remote utilities. CPSOCKET gathers information from the 
NEB or the printer, as needed, monitors requests to write to 
the log file, monitors application requests for device status, 
and maintains job statistics, as discussed above. 

Briefly, the CPSOCKET program is a method of inter- 
facing an interactive network board between the network 
and a peripheral device, comprising the steps of transferring 
a program from board ROM to board RAM for execution 
from the RAM; and monitoring, with the program, a board 
network interface to detect a network communication 
directed to the peripheral device. The program then com- 
mands the peripheral device to perform a function in 
response to the network communication, and monitors a 
board bi-directional peripheral interface to detect and store 
status information of the peripheral device. Finally, the 
program outputs the peripheral device status information 
onto the network through the network interface in response 
to another network communication. 

In FIG. SB, Steps S15 and S17 indicate "run-time" layer 
functions, and Step S20 represents a "soft-time" application 
layer. First, Step S15 determines whether data is being 
received over the LAN. When LAN data is received, the 
process proceeds to Step S16 and the software protocol type 
is determined (to be discussed in greater detail in section 4f 
below). For example, the Ethernet data received over the 
LAN may be one of the following software protocols: e.g. 
NetWare® over SPX/IPX; UNIX over TCP/IP; or Mac 
Systems 7 over AppleTalk. Basically, the software protocol 
type may be determined according to the frame packet type 
sensed in Step S7 above. 

If CPSOCKET determines that LAN data is not being 
received in Step S15, Step S17 determines whether SCSI 



03/02/2004, EAST Version: 1.4.1 



5,623 

19 

data is being received, and if SCSI data is being received, it 
is input from the printer in Step S18, and then stored in 
DRAM 220 in Step S19. 

After the storing of printer data in Step S19, or if SCSI 
data is not being received in Step S17, the process proceeds 5 
to Step S20 where "soft-time" tasks are performed on a 
multi-tasking basis as controlled by a multi-tasking software 
program called "MONITOR" (to be discussed in greater 
detail in section 41 below). Step S20 is therefore a "back- 
ground" process which runs concurrently throughout the 10 
flowchart depicted in FIGS. 5A, 5B and SC. That is, when- . 
ever "soft-time" tasks are being performed, the micropro- 
cessor 216 will ensure time-shared, parallel, non-preemptive 
processing of the "soft-time" tasks. 

More particularly, MONITOR is a software module 15 
downloaded from EPROM 222 to DRAM 220 in Step S6. 
MONITOR is a non-preemptive multitasking monitor which 
distributes the processor usage among the several applica- 
tion tasks which are currently active. The non-preemptive 
nature of the monitor requires that each application task 20 
periodically relinquish control so that other tasks gain the 
opportunity to execute. The relinquish control mechanism is 
implemented using a software interrupt to pass control to the 
MONITOR. At an interrupt, MONITOR saves the state of 
the current task, restores the state of another active task, and 25 
resumes (or commences) execution of the new task. The task 
which originally relinquished control eventually regains 
control at the interrupt point, i.e. with its context restored to 
the same condition as when it relinquished control. 

In summary, Step S20 comprises the step of monitoring a 30 
plurality of application tasks in a multi-tasking interactive 
network board to distribute processor resources. A memory 
stores a first application task which may queue a file server 
to get a network interface to obtain a queue of print files to 
be printed, and which channels the print files to a printer 35 
coupled to the board through an interface. The memory also 
stores a second application task which may receive remote 
status inquiries over a LAN interface, interrogate the printer 
over a bi-directional interface to obtain printer status and a 
response to the received status inquiry, and provide the 40 
status information over the LAN interface to the status 
requester. The first and second application tasks each include 
a relinquish command which causes the currently executing 
application task to periodically relinquish control to the 
MONITOR. The MONITOR saves the state of the relin- 45 
quishing task, restores the state of the non-relinquishing 
task, and resumes execution of the non-relinquishing task. 

In FIG. 5C, presuming that data has been received over 
the LAN at Step S15, Step S21 determines whether the 
received data is for a print job or not. If it is for a print job, 50 
microprocessor 216 acts as the LAN file server for an active 
print file and transfers print job blocks to DRAM 220 at Step 
S22. 

At Step S23, microprocessor 216 assembles blocks of 
image data and control information, and sends the blocks to 55 
the printer through the SCSI interface. In this step, the 
microprocessor 216 effectively adds "beginning of job" and 
"end of job" indications to the data stream received over the 
LAN. It does this by opening the XP (data) channel at the 
beginning of a print job, and by closing the XP channel at the 60 
end of a print job. 

At Step S24, the process waits until the print job is 
complete. Once the print job is complete, Step S25 will 
unambiguously set the printer to a default environment. It is 
also possible to set the default configuration before (or 65 
during) the print job. That is, the NEB itself will ensure that 
the attached printer is set to a default environment which 
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specifies, for example, default fonts, papers trays, collation, 
stapling, etc., to insure that the next print job will be started 
with the printer in a known configuration (to be discussed in 
greater detail in section 4m below). 

Step S25 may be thought of as guaranteeing a safe 
environment for the printer by ensuring that the printer 
settings (e.g. portrait mode, duplex, etc.) are returned to 
between logical printing jobs. For example, while Novell 
NetWare© includes the ability to prefix every job with 
printer escape sequences to reset the printer environment, 
such escape sequences reside in a database on the network 
file server, and the print job in question might not originate 
from that file server. In order to ensure a guaranteed safe 
environment, the NEB will store the requisite configuration 
parameters, and will be responsible for resetting the printer 
environment between print jobs. 

In summary, a method for providing a default configura- 
tion to a LAN printer having an interactive network board 
coupled thereto includes the step of receiving a default 
configuration over a LAN interface at the interactive net- 
work board. Hie default configuration may be stored in 
NVRAM 228 in the NEB or stored in an NVRAM or disk 
in the printer over the bi-directional interface between the 
board and the printer. Then, the default configuration is 
downloaded from the NVRAM in the printer to the DRAM 
220 on the board over the bi-directional interface. When the 
board receives print information over the LAN interface and 
provides the print information to the printer over the bi- 
directional interface, the board detects an end of print job. In 
response to this detection, the default configuration is sent to 
the printer whereby the printer is set in its default configu- 
ration. 

Additionally, a plurality of default configurations may be 
stored, and an appropriate default configuration may be 
selected remotely from another LAN entity. For example, a 
method of setting one of a plurality of default configurations 
may include a step of detecting, at the board, the origination 
of a print job and identifying the source of the job. Subse- 
quently, an appropriate default configuration is selected 
from among the stored configurations, and the selected 
default configuration is then sent to the printer at the 
beginning or end of the print job. 

In FIG. SC, if it is determined that a print job is not 
required at Step S21, Step S26 determines whether a status 
request has been made over the LAN requesting the status of 
the attached printer. If it is determined that a status request 
has been received, Step S27 determines the type of status 
request For example, printer status such as error codes, the 
number of pages printed, the toner status, etc, may be 
requested. 

At Step S28, the microprocessor 216 retrieves the 
requested status data from DRAM 220, assembles the status 
data, and sends it to the LAN through the LAN interface (to 
be discussed in greater detail in section 4i below). Thus, in 
Step S28, more than simple "on/off' information may be 
transmitted to the LAN so as to inform the LAN of the 
detailed status of the printer. In abroad application, Step S28 
encompasses the export of printer front panel status over the 
LAN, and the import of front panel control commands from 
the-LAN. That is, the network administrator at the PC 14 
may request and receive a display indicating all of the printer 
information included on the printer front panel display 116. 
Hie network administrator may then activate different 
printer front panel functions on his/her PC, and such func- 
tions will be transmitted to the printer where the selected 
control will be effected. 

In summary, at Step S28, a method for remotely control- 
ling a manually-operable function of a networked printer 
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through an interactive network board having a LAN inter- 
face for LAN communication, comprises the step of issuing, 
at a remote location, a command to the board that will cause 
the board to transfer printer status information through the 
board to the remote location through the LAN interface. At 5 
the remote location, a printer status may be displayed, and 
a second command may be issued at the remote location to 
the board through the LAN interface to cause the board to 
perform a manually-operable function. 

If the received LAN data is neither a print job nor a status 10 
request, it is determined at Step S29 that the received data 
may be a download operation, i.e., a transfer of data into the 
NEB for updating the ROM or RAM applications, e.g. 
download may be utilized for transient diagnostics to be run 
on the NEB. 15 

First, at Step S30, the data is downloaded from the LAN 
to the DRAM 220 (to be discussed in greater detail in section 
4n below). That is, the download is a process by which data 
may be loaded into a network node and then acted upon or 
executed. For example, anything from patch code, to manu- 20 
facturing test routines, to firmware updates for the EPROM 
may be downloaded. Also, application modules may be 
stored in the LAN file server and then downloaded to the 
NEB every morning. 

In summary, the downloading of data from LAN to 25 
DRAM comprises a method for altering an operational mode 
of an interactive network board having a LAN interface, 
including the step of activating a LAN communication 
program for execution from DRAM, the communication 
program channelling print information on the LAN to a 30 
peripheral printer. Executable instructions which correspond 
to the altered operational mode are then downloaded into 
DRAM via the LAN interface. The board is then com- 
manded via the LAN interface to begin execution of the 
altered operational mode. 35 

At Step S31, it is determined whether the downloaded 
information is destined for EPROM 222 or DRAM 220. If 
the information is destined for EPROM, a ROM image is 
assembled at Step S32 (to be discussed in greater detail in 
section 4o below). For example, downloading of EPROM 40 
firmware from a remote location provides unique flexibility. 
In particular, downloading of on-board test routines, and 
changing EPROM configuration firmware can be performed 
from a remote location after the board is installed in the 
printer. 45 

Step S32 is the process which constructs the binary image 
file which is to be programmed into the EPROM 222. The 
data destined for the EPROM is first downloaded to DRAM 
220 where a utility reads a configuration file containing the 
names of the modules to be placed in the ROM image. Then, 50 
a complete binary image file is constructed containing all of 
the specified modules. A header precedes each module in the 
image, the header identifying the module, describing its 
attributes, and pointing to the succeeding header to aid in 
locating the modules during loading. The last module loaded 55 
in the EPROM is the EPROM-resident code. It is placed at 
the end of the ROM image so that the power-up initialization 
code resides at the address expected by the microprocessor 
216. 

In summary, Step S32 comprises a process for formatting so 
a binary image file which contains executable code modules 
for storage in the EPROM. First, a configuration file is read 
which specifies the code modules which form the binary 
image. Next, a header is formed for each module specified 
in the configuration file, the header including an identifica- 65 
tion of the module, a definition of the module's attributes, 
and a pointer to a header for a succeeding module. The 



binary image file is then constructed containing the specified 
modules and their associated headers. Finally, a module of 
ROM-resident code is appended to the binary image, the 
ROM-resident code receiving control at power-up, provid- 
ing POST, loading at least some of the modules from the 
binary image file into DRAM 220, and providing basic 
board I/O services. 

Before writing new data into EPROM 222, it is first 
necessary to unequivocally ensure that a write operation is, 
in fact, intended. Obviously, any accidental writings into 
EPROM 222 could render the NEB unusable. Therefore, 
before information may be "flashed" to EPROM 222, a 
specified sequence of events will occur in Step S33 in order 
to access the EPROM (to be discussed in greater detail in 
section 4p below). In the present embodiment, unless two 
data bits are changed in two separate I/O locations, the ±12 
Volts necessary to write to the EPROM will not be provided. 

Briefly, a method of ensuring that the EPROM is not 
accidentally written into comprises a method of performing 
a flash operation on an EPROM resident on an interactive 
network board having a processing unit and a memory, 
including the step of sending an I/O write signal to the 
processing unit. Then, the processing unit generates a first 
address in the memory to cause a first bit to be in a 
predetermined state in response to the I/O signal. A power 
unit is then caused to provide +12 Volts to a transistor in 
response to the first bit being placed in the predetermined 
state. Then, an I/O receive signal is sent to the processing 
unit which generates a second address in the memory to 
cause a second bit to be in a preselected state in response to 
the I/O receive signal. Then, the transistor is turned on in 
response to the second bit being placed in the preselected 
state causing the +12 Volts to flow to a power terminal of the 
EPROM, allowing a write operation to take place. 

Before the new ROM image is actually stored in EPROM 
222, at Step S34 the new ROM image must be check- 
summed and verified with a checksum value sent after the 
ROM image is received. Prior to erasing EPROM 222, data 
and modules to be preserved, such as the MAC address, 
must be loaded into DRAM 220 within the new ROM 
image. 

After determining that the ROM image is verified and 
after preserving all required data into the new ROM image 
stored in DRAM 220, it is necessary to clear and erase 
EPROM 222 to ensure no corruption of data upon loading of 
the new ROM image. Accordingly, at Step S35, EPROM 
222 may be erased a plurality of times before the new ROM 
image is stored therein. 

After erasing EPROM 222 at Step S35, the new ROM 
image is "flashed" into EPROM 222 in Step S36 (to be 
discussed in greater detail in section 4q below). 

In summary, Step S36 relates to a method for remotely 
altering programmable firmware on an interactive network 
board having a LAN interface including the step of activat- 
ing a LAN communication program for execution from 
DRAM on the board, the communication program channel- 
ling print information on the LAN to a peripheral printer. A 
ROM firmware image is then downloaded to the DRAM on 
the board via the LAN interface. It is next confirmed that the 
ROM image has been downloaded to the target board, and 
the integrity of the ROM image is confirmed. The board is 
then commanded to electronically erase the EPROM, and 
then the EPROM is flashed with the new ROM image. 
Additionally, a "flash complete" signal may be sent to the 
LAN after the flash operation, if desired. 

After the information is flashed to the EPROM 222, the 
NEB is then re-booted from the new ROM firmware image 
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in EPROM 222 at Step S37, and the process returns to Step 
SI. 

In FIG. 5C, if Step S31 determines that RAM information 
is being downloaded, such information is first assembled in 
DRAM 220 via Step S38. Subsequently, Step S39 executes 5 
the RAM program, and the process returns to Step S13 
wherein SAPSERVER advertises PSERVER and 
CPSOCKET entities. 

This discussion concludes the overview of the NEB 
structures and functions when the NEB is installed in io 
LAN-networked printer. A more detailed description of the 
operation of various aspects of the NEB hardware and 
software will now be provided. 
4a. Power-On Sequence 

Immediately following power-on, NEB 2 executes a 15 
power-on self test (POST), following which the NEB loads 
operational software from EPROM 222 into DRAM 220 for 
execution. 

More specifically, immediately following power-on, 
microprocessor 216 accesses POST program modules 20 
located in EPROM 222. Microprocessor 216 executes POST 
directly from EPROM 222 to test the functionality of the 
microprocessor, integrity of the programs stored in EPROM 
222 (for example, via checksum verification), operability of 
DRAM 220 (for example, through read/write cycles), oper- 25 
ability of SCSI controller 224, data integrity of NVRAM 
228, and operation of control register 230. POST may also 
include a comparison of the MAC address stored in PROM 
232 with a MAC address downloaded into EPROM 222. 

POST further includes operational checks of network- 30 
related hardware. More specifically, POST may include 
operability checks for SRAM 214 (for example, through 
read/write cycles), as well as a check of network activity to 
verify operation of network controller 206. 

Operation of other hardware in NEB 2 may be determined 35 
directly through additional POST testing. In some cases, 
where it is not possible for microprocessor 216 to test 
operation of hardware directly, as in the case of connectors 
202, 203 and 204, proper operation of that hardware may be 
implied through result codes received from direct testing. 40 

Upon termination of POST, microprocessor 216 puts a 
checksum code onto serial port 218 and then enters a 
window of quiescent operation (for example, a one second 
window) during which microprocessor 216 can receive 
commands (e.g. for testing — see paragraph 5 below) via 45 
serial port 218. The POST checksum code may be obtained 
by a device coupled to serial port 218 to determine the 
outcome of POST. For example, a no error condition may be 
indicated by a POST checksum code of "0000h" , while a 
POST checksum code indicating an error may be indicated 50 
by a non-zero hexadecimal value which indicates the area of 
failure. In the case of failure, microprocessor 216 may also 
illuminate LED 240 on NEB 2 to signal to a user that an 
error has been detected. Preferably, LED 240 is illuminated 
on power-up and is only turned off if POST is successful. 55 

Following successful completion of POST and in the 
event that no commands are received via serial port 218 
during the one second quiescent window of activity, micro- 
processor 216 begins to load software modules stored in 
EPROM 222 into DRAM 220. Microprocessor 216 does not 60 
execute those software modules directly from EPROM 222, 
but rather loads those modules into DRAM 220 for execu- 
tion from DRAM 220. By virtue of this arrangement, it is 
possible to select the specific modules that are retrieved 
from EPROM 222 for execution out of DRAM 220 so as to 65 
permit flexible configuration of NEB 2 (see section 4d 
below). For example, in accordance with a configuration 
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command stored in NVRAM 228, microprocessor 216 may 
retrieve selective modules from EPROM 222 for loading 
into DRAM 220 and for execution from the DRAM. 

FIG. 6 shows the sequence by which different modules are 
retrieved from EPROM 222 and loaded into DRAM 220. In 
Step S6001, microprocessor 216 loads the SCSI driver from 
EPROM 222 into DRAM 220. The SCSI driver provides for 
operational sequence and control over SCSI controller 224 
and permits interface with printer 4 so as to send printer 4 
print data and so as to send and receive control information 
to and from printer 4. 

In Step S6002, microprocessor 216 loads the link support 
layer, or "LSL'\ from EPROM 222 into DRAM 220, and in 
Step S6003 microprocessor 216 loads network driver soft- 
ware from EPROM 222 into DRAM 220, and thereupon 
microprocessor 216 begins to execute the link support layer 
and the network driver from DRAM 220, The link support 
layer and the network driver provide common access to 
LAN communications on LAN bus 6. More particularly, as 
shown in FIG. 7, all networked devices, including a device 
such as NEB 2, interface with LAN bus 6 via an electrical 
interface 301 such as the network controller 206 used on 
NEB 2. The electrical interface 301 is driven by network 
driver 302 which in tum receives LAN frame data from link 
support layer software 304. Both the link support layer 304 
and the network driver 302 are common to different kinds of 
network software. For example, as further shown in FIG. 7, 
network application programs, such as those provided in 
NetWare© software by Novell (as illustrated at Arrow A) 
interface with the link support layer and the network driver 
via an internetwork packet exchange program, or 'IPX", 305 
and a sequenced packet exchange program, or "SPX" 306. 
On the other hand, network application programs from 
UNIX provided by AT&T (as illustrated at Arrow B) inter- 
face to the LSL through "IP" module 315 and 'TCP" module 
316. 

In NEB 2, only one type of network application programs 
is normally executed at any one time (although multiproto- 
col operations are possible as discussed in section 4f below). 
Explanation here will be made for NetWare® network 
application programs although it is also possible for UNIX 
network application programs to be executed as well. 

In Step S6004, microprocessor 216 loads a PRESCAN 
program from EPROM 222 and stores it into DRAM 220, 
and thereupon begins executing the PRESCAN program 
from DRAM 220. PRESCAN software interfaces with the 
link support layer to determine the frame packet type being 
transmitted on LAN bus 6. More particularly, as described 
above, there are four different possible frame packet types 
on an Ethernet-type network LAN bus: Ethernet 802.3, 
Ethernet II, Ethernet 802.2, and Ethernet SNAP. As 
described more fully below in section 4e, the PRESCAN 
software module monitors network communications on 
LAN bus 6 to determine the frame packet type. The frame 
packet type, once determined by PRESCAN, is stored in a 
predetermined common location in DRAM 220 for use by 
other network communication modules in the NEB. After 
determining the frame packet type, PRESCAN signals 
microprocessor 216 that its tasks are completed and allows 
microprocessor 216 to overwrite the memory occupied by 
the PRESCAN program with another program module. 

In Step S6005 microprocessor 216 retrieves the IPX and 
SPX program modules from EPROM 222 and stores them in 
DRAM 220, and thereupon begins executing the IPX and 
SPX modules from DRAM 220. Both IPX and SPX use the 
frame packet type determined by the PRESCAN module. 

In Step S6006 microprocessor 216 retrieves the CNETX 
program module from EPROM 222 and loads that module 
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into DRAM 2 20 a nd thereupon begins execution from 
DRAM 220. CNETX provides localized DOS-like function- 
ality to the NEB. 

In Step S6007, microprocessor 216 loads the SAPS- 
ERVER program module from EPROM 222 into DRAM 5 
220 and begins executing the SAPSERVER module from 
DRAM 220. As described more fully below in section 4g, 
SAPSERVER is a program module which allows two net- 
work server entities, such as CPSOCKET and CPSERVER, 
to advertise simultaneously from the single network node 
assigned to the NEB board, even though conventional net- 
work application programs such as those provided by Net- 
Ware® only permit advertising of a single network server 
entity from each network node. 

In Step S6008 microprocessor 216 retrieves the non- 
preemptive multi-tasking MONITOR (see section 41 below) 15 
from EPROM 222 and stores it into DRAM 220 and begins 
executing the multi-tasking monitor from DRAM 220. 

In Step S6009 microprocessor 216 retrieves the 
CPSOCKET server software module from EPROM 222 and 
loads it into DRAM 220 and begins executing the 20 
CPSOCKET server from DRAM 220. As will be described 
more fully below in section 4j, CPSOCKET initiates a 
request to SAPSERVER to advertise on behalf of 
CPSOCKET, and SAPSERVER begins making SAP adver- 
tisements on LAN bus 6. 25 

In Step S6010 microprocessor 216 retrieves print appli- 
cation servers such as CPSERVER or CRPRINTER from 
EPROM 222 and loads the print application servers into 
DRAM 222. In the case of CPSERVER, microprocessor 216 
begins executing the loaded print application servers from 30 
DRAM 220 which in turn requests SAPSERVER to make 
SAP advertisements on behalf of the print server. As 
described more fully below in section 4g, SAPSERVER 
interleaves advertisements for the CPSOCKET server and 
for the print server thereby acting as a surrogate SAP entity 35 
for both the CPSOCKET server and the print server. 
4b. Interfacing A Peripheral With A Local Area Network 

According to the broad aspects of the present invention, 
a peripheral such as a printer is coupled to a LAN using an 
interactive network board having software programs embed- 40 
ded therein. Preferably, the connection between the printer 
and the NEB is an SCSI interface so that large amounts of 
print data and status data are carried bi-directionally 
between the NEB and the printer. EPROM 222 stores a 
plurality of software modules for operationally configuring 45 
the NEB in the PSERVER or RPR1NTER or LPR functional 
configurations. The EPROM 222 also stores a number of 
status control software modules for exporting status infor- 
mation from the printer over the LAN, and for importing 
control information from the LAN to the printer. The 50 
EPROM-resident firmware is downloaded to the DRAM 220 
upon power-up (as discussed in section 4a above), whereby 
the MONITOR multi-tasking program executes soft-time 
tasks until run-time interrupts are received from either the 
LAN or SCSI interfaces. 55 

NVRAM 228 stores a configuration word which specifies 
which modules stored in EPROM 222 should be down- 
loaded into DRAM 220 in order to configure the NEB with 
either a PSERVER or RPRINTER functionality. The micro- 
processor 216 executes the programs from DRAM 220, 60 
allowing print jobs to be received from the LAN and sent to 
the printer for printing, and allowing printer status to be 
returned over the LAN in response to a status request. 

The particular details of the structure and functions for 
interfacing the peripheral to the local area network are set 65 
forth above with reference to FIGS. 4, 5A, SB and 5C, and 
in the following sections. 
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4c. The Bi-Directional Interface Between The Local Area 
Network And The Printer 

The provision of a bi-directional SCSI interface between 
the NEB 2 and the printer permits a large amount of status 
information to be extracted from the printer, while still 
providing the print data to the printer. Further, by utilizing 
the bi-directional SCSI interface, the printer can respond to 
control commands issued from a remote location over the 
LAN. For example, the network administrator may issue a 
control command from his/her PC 14 that requests a par- 
ticular print job be printed a plurality of times, with high 
image density, and then stapled. Such control commands are 
sent to the NEB 2 over the LAN 6, and the NEB 2 transmits 
these control commands to the printer through the SCSI bus 
102. At the same time, the actual print data is transferred 
from file server 30 to the NEB 2, where the print data is 
packaged in blocks and transferred to the printer over the 
SCSI bus 102. Preferably, the NEB 2 indicates the "start of 
print job" by opening the XP data channel to the printer. 
Likewise, the NEB 2 indicates "end of print job" by closing 
the XP data channel to the printer. Therefore, the NEB 2 can 
provide such indications to the printer. 

The use of the bi-directional SCSI interface on the NEB 
2 also permits other types of peripherals to be coupled to the 
LAN. For example, since the SCSI interface is capable of 
transmitting large quantities of data to the LAN from the 
peripheral, it is possible to couple the NEB to an image data 
generating device such as a scanner (e.g., where printer 4 is 
an Optical Character Recognition ("OCR") device) or a 
facsimile machine. Thus, data produced by the image gen- 
erating device may be transferred to the NEB over the SCSI 
interface, and then put on the LAN for storage or retrieval 
by any of the LAN entities. As with a printer, large quantities 
of detailed control/status information can also be provided 
to/from the image data generating device. 

The detailed structural and functional features of the 
bi-directional SCSI interface on the NEB are set forth above 
with reference to FIGS. 4, 5A, SB and 5C, and in the 
following sections. 
4d. ROM 

As described earlier with respect to FIG. 5A, Step S6 
downloads selected software programs from EPROM 222 to 
the DRAM 220 for execution (see also FIG. 6 and section 
4a). The EPROM 222 is delivered with firmware modules 
which permit the NEB 2 to be configured with either 
RPRINTER or PSERVER functionality. Therefore, the func- 
tionality of the NEB 2 will be determined by which of the 
stored programs are downloaded from EPROM 222 to 
DRAM 220 in accordance with the configruation code 
stored in NVRAM 228. 

The NEB 2 firmware is configured initially, and can be 
reconfigured subsequently by running CPENIT on the net- 
work administrator's PC 14 (see section 4h below). How- 
ever, even in an unconfigured state, NEB 2 itself will always 
activate those software modules needed to perform basic 
communication with the LAN. Using CPINTT, the network 
manager can determine, remotely, the current configuration 
of the NEB, or he/she can change the configuration as 
desired. Since the configuration information is stored in 
EPROM on the NEB board, the configuration information is 
retained across power cycles. 

The process by which the software programs for a par- 
ticular configuration are downloaded from the EPROM 222 
to the DRAM 220 will be described below with respect to 
FIG. 8. 

After the board has been powered up at Step SI, the 
process proceeds to Step S8001 where microprocessor 216 
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accesses EPROM-resident code in the EPROM 222 to read 
a configuration code (typically a word) from NVRAM 228. 
The configuration code will specify modules which can 
provide the NEB with either a PSERVER or RPRINTER 
functionality. Although the present embodiment includes 5 
only RPRINTER or PSERVER functional configurations, 
other configurations may be utilized where, for instance, the 
NEB 2 is installed in a dilferent LAN entity, such as a 
scanner or a facsimile machine. 

After reading the configuration code from NVRAM 228, 10 
the microprocessor, at Step S8002, forms a configuration 
mask whose bit pattern corresponds to the read configuration 
code. At Step S8003, a loader module resident in EPROM 
222 compares the configuration mask to the plurality of 
firmware modules stored in the EPROM 222. 15 

In detail, in Step S8004, a process begins whereby the 
EPROM-resident software modules are selected in bit- wise 
correspondence to the binary digits of the configuration code 
read from NVRAM 228. If it is determined in Step S8004 
that the currently-examined bit of the bit pattern matches a 20 
stored module, then that module is selected (at Step S8005) 
for downloading to DRAM 220, and the process skips to the 
next bit at Step S8006. Likewise, if Step S8004 determines 
that a bit of the bit pattern does not match the stored module, 
the process skips to the next bit at Step S8006. 25 

At Step S8007, it is determined whether the bit tested in 
Step S8004 is the last bit of the configuration mask bit 
pattern. If the tested bit is not the last bit, the process loops 
back to Step S8004, where the next bit of the bit pattern is 
tested with respect to the next stored module. When the last 30 
bit of the configuration mask bit pattern has been tested, the 
selected software module are downloaded from EPROM 
222 to DRAM 220 at Step S8008. 

In the present embodiment, the software modules are 
loaded in the following sequence: SCSI Driver; Link Sup- 35 
port Layer; Network Driver; Prescan; IPX/SPX; CNETX; 
SAPSERVER; MONITOR; CPSOCKET; and Print Appli- 
cations (e.g. CPSERVER, CPRINTER) (see FIG. 6). 

After all of the software modules which correspond to the 
configuration codes stored in NVRAM 228 have been 40 
downloaded to DRAM 220, the loader function will pass 
program execution contort to the MONITOR multi-tasking 
program at Step S8009. 

As discussed earlier, the configuration code stored in 
NBRAM 228 may be remotely altered using CPINIT. This 45 
provides greater flexibility for making minor modifications 
to CPSERVER or CRPRINTER, or where entirely new 
configurations are desired to be set. Therefore, at Step 
S8010, a new configuration is received over LAN 6, and is 
loaded into NVRAM 228 at Step S80LL Preferably, teh old 50 
configuration code will be erased or overwritten with the 
new configuration code. Then, the NEB reboots itself and 
returns to Step SI. 

4e. Determining Frame Packet Type Using PRESCAN 

On any local area network, data is transmitted between 55 
network devices in packets or frames. But even in the 
context of a common network architecture, such as Ethernet, 
more than one format for the frame may be supported. Thus, 
even though it is known that Ethernet architecture is being 
used, it is not possible to determine the arrangement of data 60 
within each physical frame or packet of information on the 
Ethernet bus. In particular, as described above, Ethernet 
supports four arrangements of data, or formats, as follows: 
Ethernet 802.3, Ethernet II, Ethernet 802.2, and Ethernet 
SNAP. 65 

In conventional network devices, which provide for a 
manually selectable operator interface, it is possible to 
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advise the network device of the particular frame type being 
used on the Ethernet network. In the context of NEB 2, for 
which operator access is provided only via the network 
interface (or via the serial port 218 in a test configuration), 
it is not possible to set the frame packet type without first 
allowing operator access to the local area network which, of 
course, requires knowledge of the frame packet type. 

The PRESCAN software module allows NEB 2 to auto- 
matically determine the frame packet type currently being 
used for LAN communication on the LAN bus by monitor- 
ing broadcast communications on the LAN bus until the 
proper frame packet type is recognized. PRESCAN makes 
this determination based on recognizable components that 
are common to all four frame packet types used on Ethernet. 

In more detail, FIG. 9 shows the physical construction of 
different frame packets used on Ethernet. As shown in FIG. 
9, a physical frame 411 being transmitted on the LAN bus 
includes a 6-byte section 412 for storing the destination 
MAC address, and a 6-byte section 413 for storing the 
source MAC address. These 12 bytes comprise the first 12 
bytes of LAN data packets regardless of the frame type 
being used for LAN communication. A data section 414 
follows these 12 bytes. The data section is comprised of a 
variable number of bytes which are not used for the same 
purposes by the different frame packet types and which do 
not have the same number of bytes for the different frame 
packet types. 

Following the indeterminate area 414, the LAN commu- 
nication packet includes an IPX header 415 the first two 
bytes of which always has the value "FFFF" (hexadecimal). 
The remainder of the packet 416 follows the IPX header and 
comprises the data and other commands which characterize 
each different type of LAN communication packet. 

PRESCAN operates by monitoring the LAN communi- 
cation in accordance with each of the different packet types 
until the common area (such as IPX header 415) is recog- 
nized in one of those packet types. PRESCAN then stores 
that packet type for use by other network communication 
programs. 

FIG. 10 is a detailed flowchart for showing operation of 
the PRESCAN module. In Step S1001, microprocessor 216 
retrieves the PRESCAN module from EPROM 222 and 
loads it into DRAM 220 and thereupon begins execution of 
the PRESCAN module. The PRESCAN module is executed 
before the SPX and IPX modules, even if microprocessor 
216 retrieves those latter modules from EPROM 222 and 
loads them into DRAM 220 before the operational sequence 
shown in FIG. 10 is complete. More particularly, proper 
operation of the SPX and IPX program modules depends 
upon the identification of the frame packet type by PRES- 
CAN and therefore execution of SPX and IPX is deferred 
until after PRESCAN determines the proper frame packet 
type 

In Step S1002, PRESCAN simultaneously binds through 
LSL to all four frame packet types, namely, Ethernet 802.3, 
Ethernet II, Ethernet 802.2, and Ethernet SNAP. That is, 
PRESCAN configures LSL such that for each packet of 
LAN communication, LSL provides a data group corre- 
sponding to each of the four frame packet types. Thereafter, 
PRESCAN goes inactive pending reactivation by an inter- 
rupt from the network driver. 

In Step S1003, the network driver monitors communica- 
tions on the LAN bus for broadcast traffic. Broadcast traffic 
means that the destination MAC address 412 is unspecified 
or is given a global specification of "FFFFFFFFFFFF" 
(hexadecimal). The network driver continues to monitor 
communications on the LAN bus for broadcast traffic (Step 
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S1004) until broadcast traffic is received, whereupon flow 
advances to Step S1005. In Step S1005, the MAC address 
fields 412 and 413 are stripped off the received data packet 
and the remainder of the data packet is provided to LSL. In 
Step S1006, LSL interprets the frame packet in accordance 5 
with each of the frame packet types and provides a data 
group in correspondence to each of the frame packet types. 
In Step S1007, the network driver reactivates PRESCAN 
which determines which data group provided by LSL has the 
proper first two bytes, of an IPX header, namely "FFFF" 10 
(hexadecimal). That is, because of the variable data area 414 
(variable data area 414 corresponding to each of the different 
packet types (FIG. 9)), LSL will properly identify the IPX 
header 415 in accordance with only one of the frame packet 
types. In Step S1007, PRESCAN searches for the IPX 15 
header and, in accordance with which of the four data groups 
is provided by LSL, it is able to determine a frame packet 
type that is currently being used on the LAN bus. 

In Step S1008 PRESCAN stores the corresponding frame 
packet type in a common area in DRAM 220 so that the 20 
frame packet type can be used by other network application 
programs such as SPX and IPX. Thereafter, in Step S1009, 
PRESCAN frees its storage area in DRAM 220 so that 
microprocessor 216 may overwrite that data area with other 
software modules, if desired. 25 
4f. Multiprotocol Operation 

In a multiprotocol operation, two different operating sys- 
tems carry on LAN communications over a single local area 
network bus, but using respectively different operating pro- 
tocols. For example, a Novell-compatible operating system 30 
communicates over a LAN bus using SPX/IPX operating 
protocol, while a UNIX-compatible operating system com- 
municates over the LAN bus using a TCP/IP operating 
protocol. Other operating systems, such as the AppleTalk® 
operating system provided by Apple Corporation, use 35 
respectively different operating protocols for LAN commu- 
nication over a single network bus in a multiprotocol net- 
work environment. 

Ordinarily, NEB 2 is configured to communicate to a 
single network operating system, but it may also be config- 40 
ured to operate in a multiprotocol network environment, for 
example, a combined Novell/UNIX multiprotocol environ- 
ment. In this configuration, NEB 2 includes a Novell- 
compatible peripheral server, such as the aforementioned 
CPSERVER, which checks job queues in a file server on a 45 
Novell operating system, as well as a UNIX-compatible 
peripheral server, such as the aforementioned CLPR (Cus- 
tom Line Printer Remote), which, in coordination with 
checks made by CPSERVER, also checks for job queues in 
a file server for a UNIX operating system. Both servers, here 50 
CPSERVER and CLPR, service common peripheral 
resources, here a single peripheral such as a printer, and to 
avoid contention for control of the common resources, both 
servers are able to seize control of the peripheral to the 
exclusion of other servers, to signal other servers that control 55 
has been seized, and to relinquish control of the peripheral 
when the job queue has been emptied. It is also possible for 
each server to check with other servers to determine if other 
servers have a pending request for use of the peripheral. In 
the case where there is a pending request, the server can 60 
relinquish control of the peripheral at the end of a current job 
even though there are jobs remaining in the job queue, so as 
to allow alternating use of the peripheral by each server. 

FIG. 11 illustrates NEB 2 configured for multiprotocol 
network operations. FIG. 11 illustrates a combined Novell/ 65 
UNIX multiprotocol environment, but it is to be understood 
that other operating protocols may be substituted for or used 



in combination with those shown in FIG. 11. In FIG, 11, 
NEB 2 is interfaced to LAN bus 6 via electrical interface 
321, network driver 322, and link support layer ("LSL") 
324, much as illustrated above in FIG. 7. Novell-specific 
operating protocols are indicated at reference numerals 325, 
326 and 327. More specifically, 325 and 326 are an SPX/IPX 
operating protocol stack (or tower) by which Novell-com- 
patible applications programs communicate with the LAN 
bus through LSL. Novell-compatible applications programs, 
including a Novell-compatible server such as CPSERVER, 
arc illustrated at 327. The Novell-compatible software 
drives printer 4 via bi-directional SCSI bus 102 as described 
above. 

UNIX-compatible operating protocols are illustrated at 
reference numerals 335, 336 and 337. More specifically, 335 
and 336 comprise a TCP/IP operating protocol stack (or 
tower) by which UNIX-compatible application programs 
communicate to LAN bus 6 via LSL. UNIX-compatible 
network application programs, including a UNIX-compat- 
ible printer server such as CLPR, are designated at 337. The 
print server CLPR drives printer 4 via SCSI bus 102 as 
described above. 

Prescan module 339 interfaces with LSL 324 to determine 
the frame packet type being transmitted on LAN bus 6 for 
each of the operating systems. In more detail, each operating 
system such as the UNIX operating system and the Novell 
operating system can communicate on LAN bus 6 in a 
variety of frame packet types. When LAN bus 6 is an 
Ethernet type LAN bus, then a UNIX operating system can 
communicate over the Ethernet by any of three frame packet 
types, namely, Ethernet 802.2, Ethernet II and Ethernet 
SNAP. Likewise, when LAN bus 6 is an Ethernet-type bus, 
then a Novell operating system can communicate over the 
LAN bus by any of four frame packet types, namely, 
Ethernet 802.2, Ethernet 802.3, Ethernet II and Ethernet 
SNAP. It is possible for both the Novell operating system 
and the UNIX operating system to use the same frame 
packet type; it is the operating system protocols (SPX/IPX 
for Novell and TCP/IP for UNIX) which determine which 
one of the operating systems in a multiprotocol environment 
is currently communicating on the LAN bus. 

In the multiprotocol environment illustrated in FIG. 11, 
PRESCAN module 339 determines the frame packet type 
being used by each operating system by repeating the steps 
shown in FIG. 10 for each of the operating system protocols 
(see section 4e above). For example, when Novell-compat- 
ible and UNIX-compatible systems comprise the multipro- 
tocol environment, then PRESCAN simultaneously binds 
through LSL to all four frame packet types for an SPX/IPX 
protocol tower, so as to determine the frame packet type in 
accordance with the data group returned from LSL which 
has the proper IPX header. Tnen, PRESCAN binds simul- 
taneously through LSL through all three frame packet types 
having a TCP/IP protocol tower. PRESCAN tetermines the 
frame packet type being used by the UNIX-compatible- 
opcrating system in accordance with the data group having 
the proper TCP/IP header. 

In more detail, to adaptively and automatically determine 
which of plural predetermined frame packet types is cur- 
rently being used for LAN communication in a multiproto- 
col network environment, the PRESCAN program module 
339 is downloaded from EPROM 222 into DRAM 220 
where microprocessor 216 executes the PRESCAN module. 
To determine the frame packet type for the first operating 
system, PRESCAN first configures LSL to bind simulta- 
neously to a plurality of frame packet types corresponding to 
a first operating system protocol, such as SPX/IPX operating 
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protocol for Novell-compatible operating systems. Network 
driver 322 monitors the LAN communication bus to capture 
broadcast traffic for the first operating system. In response to 
capturing such broadcast traffic, LSL provides plural data 
groups for the captured broadcast traffic, each of the data 5 
groups corresponding to a different one of the plural packet 
types. The PRESCAN module 339 is reactivated to prescan 
each data group for the presence of a predetermined header, 
such as the SPX/IPX header, and stores the frame packet 
type corresponding to the data group having the predeter- 10 
mined header for use by the first operating protocol tower. 

To determine the frame packet type being used for the 
second operating system such as a UNIX operating system, 
PRESCAN configures LSL to bind simultaneously to a 
plurality of frame packet types corresponding to the second 15 
operating system protocol, such as TCP/IP for a UNIX 
operating system. The network driver monitors the LAN 
communication bus to capture broadcast traffic for the 
second operating system, and provides plural data groups 
corresponding to the captured broadcast traffic, each of the 20 
data groups corresponding to a different one of the packet 
types. The PRESCAN module prescans each data group for 
the presence of a predetermined header, such as the TCP/IP 
header for UNIX, and stores the frame packet type corre- 
sponding to the data group having the predetermined header. 25 

Once knowledge of the frame packet types being used by 
each of the operating systems in the multiprotocol environ- 
ment has been obtained, the Novell-compatible network 
application programs 327, such as CPSERVER, and the 
UNIX-compatible network application programs 337, such 30 
as CLPR, can both communicate on the LAN bus 6. The two 
application programs 327 and 337 also communicate with 
each other as illustrated schematically by signalling line 
340. Using signalling line 340, which may be implemented 
as a control register stored in DRAM which is commonly 35 
accessed by programs 327 and 337, programs 327 and 337 
can communicate with each other so as to signal that one of 
them has seized exclusive control over printer 4 or to signal 
that one of them has a pending request for use of printer 4, 
as will be described more fully hereinbelow. 40 

In operation, a first server such as CPSERVER, checks its 
operating system job queue, and if there is print information 
in the job queue, receives the print information from its 
operating system. In coordination with job queue checks by 
the first server, the second server such as CLPR checks its 45 
operating system job queue and, if there is print information 
in the job queue, receives job information from the operating 
system. When one of the servers has acquired sufficient 
information to require use of the printer peripheral, it seizes 
exclusive control of the printer, and signals to other servers 50 
via signalling line 340 that it has exclusive control of the 
printer. This prevents contention problems whereby other 
servers may inadvertently try to insert print jobs into printer 
4. 

The first server retains exclusive control over printer 4 55 
until its job queue has been emptied. When its job queue has 
been emptied, the first server relinquishes control of printer 
4 after which it may be used by any of the other servers. 

Alternatively, even though the first server's job queue 
might not yet be empty, when the first server reaches the end 60 
of a print job, the first server may interrogate other servers 
via the signalling line 340 to determine if the other servers 
have requests pending for the use of printer 4. If other 
servers have requests pending, then the first server may 
temporarily relinquish control of the printer so as to permit 65 
alternating use of the peripheral by each of the servers. In 
this case, when the first server relinquishes control over the 



printer, it also signals that it has a pending request for use of 
the printer. 

4g. Advertising Multiple Servers From A Single Network 
Node Using Sapscrver 

As mentioned above, NetWare® only allows a single 
network server from each non-fileserver network node to 
advertise its services on the LAN bus. However, in the 
multi-tasking environment established by the non-preemp- 
tive MONITOR, NEB 2 provides more than one network 
server. In particular, NEB 2 provides the services of the print 
server (CPSERVER, CRPRINTER or CLPR) as well as the 
services of the socket server (CPSOCKET). The SAPS- 
ERVER program module allows both network servers to 
advertise their services from a single network node, here the 
NEB, in a LAN communication system which normally 
supports advertising of only a single network server from 
each node. SAPSERVER accomplishes this by acting as a 
surrogate server (or SAP'ing entity) from the NEB which 
interleavedly advertises the services of each of its client 
servers, here CPSOCKET and CPSERVER. 

SAPSERVER listens to the network for SAP broadcast 
requests directed to one of its clients and responds with the 
server type of its client, the server name, and a communi- 
cation socket number by which the client can establish direct 
LAN communication. 

FIG. 12 is a view for explaining the software structure of 
SAPSERVER, and FIG. 13 is a flow diagram for explaining 
operation of SAPSERVER. 

As shown in FIG. 12, SAPSERVER is positioned in the 
software hierarchy at the application level of software so 
that it can communicate directly with the SPX and IPX 
network levels of software. SAPSERVER acts as a surrogate 
SAP'ing entity for each of its clients which in the case of 
NEB 2 consists of the socket server program CPSOCKET 
and the print server program CPSERVER as designated by 
the configuration of the board. SAPSERVER may also be 
configured to serve other clients as well, as illustrated 
diagrammatically at "CLIENT N". 

As shown in FIG. 13, after microprocessor 216 retrieves 
the SAPSERVER program module from EPROM 222 and 
stores it in DRAM 220, microprocessor 216 commences 
operation of the SAPSERVER program and configures it to 
listen for SAP proprietary broadcasts to the SAP proprietary 
socket (Step S1301). In Step S1302, after microprocessor 
216 retrieves the CPSOCKET module from EPROM 222 
and stores it for execution in DRAM 220, the CPSOCKET 
program module issues a request to SAPSERVER to adver- 
tise CPSOCKET services. In accordance with standard SAP 
protocol, SAPSERVER commences periodic advertisements 
for CPSOCKET (Step S1303), for example, at one minute 
intervals. 

In Step S1304, after microprocessor 216 retrieves the 
CPSERVER module from EPROM 222 and stores it for 
execution from DRAM 220, CPSERVER issues a request to 
SAPSERVER for SAPSERVER to advertise CPSERVER 
services over the network. SAPSERVER commences peri- 
odic SAP advertisements for the services of CPSERVER and 
also continues to advertise the services for CPSOCKET. As 
shown in Step S1305, the advertisements are interleaved. 

Step S1306 determines whether a broadcast request has 
been received at the SAP proprietary socket (e.g. socket 
number 453). Until a broadcast request has been received at 
the proprietary socket, SAPSERVER simply continues to 
interleavedly advertise for the services of CPSERVER and 
CPSOCKET. However, when a broadcast request is received 
at the proprietary socket then in Step S1307 SAPSERVER 
determines whether the broadcast request is for the services 
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of one of its clients, here for the services of CPSOCKET or 
CPSERVER. If the broadcast request is not for one of 
SAPSERVER* s clients, then flow simply returns to Step 
S1305 where SAPSERVER continues to interleavedly 
advertise for its clients. On the other hand, if the broadcast 5 
request is for one of SAPSERVER' s clients, then flow 
advances to Step S1308. 

In Step S1308, SAPSERVER responds with an IPX 
packet on the proprietary socket number 453. The IPX 
packet contains the server type of its client, the server name, 10 
and a communication socket number. The IPX packet also 
designates a communication socket over which the broad- 
cast requestor can establish direct communication with the 
client. Thereupon, SAPSERVER returns to Step S1305 so as 
to continue to interleavedly advertise for each of its clients. 15 

In Step S1309, the broadcast requester establishes direct 
SPX connection with the client designated in the broadcast 
request over the communication socket designated in Step 
S1308. In the present configuration, where services of the 
print server CPSERVER is requested, the socket number is 20 
8060. On the other hand, when requests for services of the 
CPSOCKET server is requested, the socket number is 83B4 
for communication and 83B5 for connection. Direct com- 
munication then proceeds as described more fully herein- 
below. 25 
4h. Configuring The Networked Printer Using CPINIT 

FIG. 14 is a flow diagram showing how a network 
administrator can use CPINIT from PC 14 to initialize and 
to configure, and later to reconfigure, both NEB 2 and printer 
4 in which the NEB resides. 30 

In Step S1401, the CPINIT utility uses a service adver- 
tising protocol (SAP) on the network to determine which 
networked printer devices are available to respond to 
CPINIT inquiries. At each of the NEB boards, CPSOCKET 
responds with server type, server name and a unique socket 35 
number by which each NEB can be accessed directly, and an 
indication of whether or not the NEB requires configuration. 

In Step S1402, CPINIT constructs a list of all NEB's and 
their associated devices, and presents them in a menu form 
so that they can be selected by the system administrator. 40 
Following selection, CPINIT requests the current configu- 
ration of the targeted NEB (Step S1403), More specifically, 
CPINIT sends a request to the targeted NEB via the LAN 
interface. At the NEB, CPSOCKET, receives the request for 
configuration information from the LAN interface. 45 
CPSOCKET collects the needed configuration information, 
and directs it via the LAN interface to CPINIT at the system 
administrator's PC 14 (Step S1404), In Step S1405, CPINIT 
displays a menu of the current configuration of the targeted 
NEB. 50 

In Steps S1406 through S1408, the system administrator 
specifies a desired configuration for the targeted board. More 
particularly, configuration is specified on the system admin- 
istrator's PC 14 by means of a user interface such as a menu 
display. The following configuration parameters are selected 55 
by the operator to set the configuration information: (1) 
logging information (Step S1406), (2) NEB name (Step 
S1407), and (3) application type (such as CPSERVER) (Step 
s 408). 

Under logging information, the system administrator 60 
specifics one of four different levels of logging: "NONE", in 
which logging is disabled "AUTO" in which basic printer 
usage statistics are logged once per day; "ERROR", in 
which basic printer usage statistics and error events are 
logged as they occur; and "JOB", in which basic usage 65 
printer statistics, error events and job start/end information 
arc all logged as they occur. After selecting the log prefer- 
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ence, the system administrator must also set the maximum 
log size (except when "NONE" is selected) so as to permit 
the printer to reserve this amount of space on its disk (or on 
its NVRAM 111 in the event there is no printer disk or in 
NVRAM 228 in the NEB) for storing log information. 

Under NEB name information (Step S1407), the system 
administrator may assign an alphanumeric name to the NEB, 
such as a descriptive name like "2nd Floor Laser". The 
descriptive name is stored by the NEB in its NVRAM and 
is used by the NEB and other network devices to assist in 
identification. 

Under application type selection (Step S1408), the system 
administrator selects whether to configure the NEB as a 
CPSERVER or a CRPRDSfTER. If CPSERVER is selected, 
it is necessary to designate the name of the print server 
assigned to the NEB, password, application buffer size, 
queue service mode, form numbers, the printer number of 
the printer in which the NEB resides, the name(s) of the print 
queue(s) serviced by the NEB, and the name of the primary 
file server. If CRPRINTER is selected, it is necessary for the 
system administrator to designate the name of the print 
server through which the NEB obtains its print information, 
the printer number of the printer in which the NEB resides, 
the name(s) of the print queue(s) serviced by the NEB, and 
the name of the primary file server. 

In Step S1409, CPINIT sends the new configuration to the 
NEB via the network LAN. At the targeted NEB, 
CPSOCKET receives the new configuration information and 
stores it in NVRAM 228 (Step S1410). 

To complete the configuration of the NEB, the NEB 
should be re-booted. The system administrator issues a 
command via CPINIT which in turn sends a command to 
re-boot via the LAN to the targeted NEB (Step S1411). At 
the NEB, CPSOCKET receives the command to re-boot, and 
re-boots the NEB in the new configuration (Step S1412). 
4i. Accessing The Networked Printer Using CPCONSOL 

CPCONSOL is a utility program executed from the sys- 
tem administrator's PC 14 by which the NEB can be used for 
maximum control and efficiency of the networked printer. 
Using CPCONSOL, it is possible to remotely track routine 
and ongoing maintenance parameters. For example, it can be 
determined if toner is low, if the paper tray is empty, if a 
page is jammed, or if the printer is not responding at all. 
CPCONSOL can also keep track of the total number of 
pages printed to schedule routine and preventative mainte- 
nance, as well as plan for eventual printer replacement. 

The CPCONSOL utility gives the system administrator 
access to statistics about the printer operation as well as the 
efficiency of network communications. CPCONSOL can 
determine the total number of pages printed, as well as the 
average page-per-minute rate, average pages-per-day, and 
other statistics that allow monitoring of the operating effi- 
ciency of the printer. 

The network statistics allow gauging the efficiency of 
communications on the network, frequency of transmit and 
receive errors as well as retries, overrun, and underrun 
errors. 

When multiple printers are installed, CPCONSOL can 
remotely keep track of each printer's usage, both in terms of 
total jobs as well as total pages. This allows job tracking 
such as for direct departmental billing for items such as 
consumable paper costs. 

By ongoing monitoring CPCONSOL can help determine 
whether to relocate or add network printers for better effi- 
ciency as well as forecast the need for replacement. 

CPCONSOL can also set up default (safe) environment 
parameters which ensure that the printer is configured the 
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same way prior to each print job (see section 4m below). The 
user, of course, can modify that configuration within the 
print job itself. 

FTG. IS is a detailed flow chart showing operation of 
CPCONSOL. Like CPINIT, CPCONSOL first broadcasts on 
the LAN to request identification of all NEB devices 
attached to the LAN (Step S1501). At the NEB's, 
CPSOCKET responds with the unique network ID's and the 
communication socket numbers assigned to the NEB (Step 
S1502). CPCONSOL collects this response information for 
all NEB's and displays a list of responding NEB's to the 
administrator (Step S1503). The administrator selects one of 
the NEB's whereupon CPCONSOL establishes direct net- 
work communication with the selected NEB by means of 
LAN broadcasts to the network ID and socket numbers. 

Once direct LAN communication is established with the 
target NEB, CPCONSOL operates by means of a user 
interface such as a menu display (Step S1504). The menu 
divides the functions of CPCONSOL into five groups: 20 
Environment, Network, Logging, Application Control, and 
Printer Status. These functional groups are detailed in the 
following sections. 
[Environment Group (Step S1505)] 

The environment selection allows CPCONSOL to display 25 
the current environment of the selected printer (Step S1506), 
and to modify and store the new environment (Step S1507). 
The environment is subdivided into four groups: Common 
Environment, Interface, Control, and Quality. 

Upon selecting Common Environment, CPCONSOL will 
initiate a LAN request to the target NEB for the settings for 
Emulation Mode, Feeder, and Total Page Count. 
CPSOCKET at the target NEB will receive the LAN request, 
obtain the desired information from its attached printer via 
the bi-directional SCSI interface, and send the information 
to CPCONSOL at the administrator's PC 14 via the LAN 
interface. There, CPCONSOL displays a listing showing the 
emulation mode, the feeder, and the total page count. 

Upon selecting the Interface menu CPCONSOL will 
initiate a LAN request to the targeted NEB for interface 40 
information. When the NEB responds, CPCONSOL causes 
the interface listing to display the interface that is currently 
seL for the selected printer. 

Selecting the Control menu likewise causes CPCONSOL 
to initiate a LAN request to the targeted NEB which in turn ^ 
interrogates its printer via the bi-directional SCSI bus for 
printer settings. The printer settings are returned to CPCON- 
SOL over the LAN interface which displays the current 
settings of the printer in accordance with T&ble 3. 

50 

TABLE 3 
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Control Information 



Description 



Contrast 

Message 
Copy 
Offset X 

Offset Y 



Printer contrast setting. 
This is the setting of the 
job time-out set in the 
printer. 

Language in which messages 
are displayed. 
Number of copies of each 
page to be printed. 
The offset, if any, in the 
horizontal direction from 
the upper left corner of 
the page, in millimeters. 
The offset, if any, in the 
vertical direction from the 
upper left comer of the 
page in millimeters. 



55 



60 



65 
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TABLE 3-continued 



Control Information 



Description 



error oiap 


Displays whether the 




printer is sat for 




automatic or manual error 




skipping. 


Buzzer 


On or Off setting of the 




printer buzzer. 


Toner Low 


If the toner low, a WARNING 




is displayed 


28-Error 


Detection of Memory Full 




error can be turned on or 




off. 


Paper 


Paper sizes that are 




available in the printer. 


Current Paper 


Paper cassette that is 




currently selected in the 




printer. 



Upon selecting the Quality group, CPCONSOL, after 
requesting and receiving information from the targeted NEB 
via the LAN interface, displays the settings for Selection 
Mode, Refine, Memory Usage and Low Resolution mode. 
[Network Group (Step S1508)] 

The network selection allows CPCONSOL to display the 
compiled statistics about the networked printer performance 
on the network (Step S1509), and to modify and store the 
new network group (Step S1510). These are subdivided into 
media-dependent and media-independent related transmit 
and receive statistics. CPCONSOL can also clear all statis- 
tics. 

When the system administrator selects the Network 
group, CPCONSOL initiates a network request via the LAN 
interface to the targeted NEB. At the NEB, CPSOCKET, 
responds to the request and obtains the needed performance 
information. The information is collected by CPSOCKET 
and returned to CPCONSOL at the administrator's PC 14 via 
the LAN interface. At the administrator's PC 14, CPCON- 
SOL displays the media-dependent and media-independent 
transmit and receive information. 

Media-dependent receive and transmit statistics are sum- 
marized in Tables. 4 and 5. 



TABLE 4 


Media-Dependent 




Receive Statistic 


Description 


CRC 


Total number of Cyclic 




Redundancy Check errors 




detected by the LBP-Remote 


Missed Frames 


Number of packets missed due 




to lack of space in the 




receive buffer, or the 




controller is in the monitor 




mode. 


Align Errors 


Indicates that the incoming 




packet did not end on a byte 




boundary. 


Received Disabled 


Controller was in the 




monitor mode. 


Deferring 


Set when internal Carrier 




Sense or Collision signals 




are generated in the 




encoder/decoder. 


Overflow 


Buffer ran out of space 




while data was being 




received from the network. 


Overruns 


The buffer did not respond 




fast enough to keep data 




from flowing from the 




network. 
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Media- Dependent 




Transmit Statistic 


Description 


Collisions 


Packet Collision Total 


Heartbeat 


Number of failures of the 




transceiver to transmit a 




collision signal after 




transmission of a packet 




with this bit set. 


Out of Window Call 


Set for the number of 




collisions that occurred 




after slot time. 


Undcrruns 


The buffer did not respond 




fast enough to keep data 




from flowing to the network. 



Media independent statistics display the network statistics 
that aren't related to the transmission media. Such statistics 
arc a good summary of overall printer activity on the 
network, and are summarized Table 6. 



TABLE 6 


Media Independent Parameter 


Description 


Abort Rx Frame 


General receive problems. 


Total Rx Frame 


Total number of received 




frames. 


Rx Too Big 


Receive frame larger than 




expected. 


Rx Too Small 


Receive frame smaller than 




expected. 


Abort Tx Frame 


General transmit problems. 


Total Tx Frame 


Total number of transmitted 




frames. 



logical order and includes the following record types. The 
precise content of the log file varies in accordance with the 
logging level set by CPINIT, as summarized in Table 7, 

TABLE 7 



Type 



10 



15 



20 



25 



30 



[Logging Group (Step S1511)] 

The logging group selection allows CPCONSOL to dis- 35 
play the set of job-related statistics that the NEB compiles 
(Step S1512), and to modify and store the new logging 
group (Step S1573). The displayed data include job aver- 
ages, page averages, and performance data. CPCONSOL 
can reset the totals to zero with this menu as well. In addition 40 
to statistics, the NEB can create a log for every print job, 
write the log to a work station disk, or clear the log file, as 
configured by CPINIT. 

If the system administrator selects the Logging Group 
option, then CPCONSOL directs a LAN request for the log 45 
file to the targeted NEB via the LAN interface. At the NEB, 
CPSOCKET receives the request and, since CPSOCKET 
stores the log file on the printer, requests the log file from the 
printer via the bi-directional SCSI interface. The NEB 
retrieves the log file from wherever it is stored (such as its 50 
disk 114) and provides the file to CPSOCKET via the 
bi-directional SCSI interface. CPSOCKET then puts the log 
file onto the network via the LAN interface for receipt by 
CPCONSOL. 

The log file includes values for the statistics which are 55 
divided into three categories: Daily, Cumulative, and Aver- 
age. Daily shows the values for the current day. Cumulative 
shows the totals for all days since last reset, or since 
power-on for a printer without a disk drive. Average is the 
cumulative totals divided by the number of days since the 60 
last reset. For each of the three categories, the NEB main- 
tains totals for the following values (unless CPINIT has set 
the logging level to "NONE"): days (number of days since 
a reset was issued or since power-on), pages printed, print 
jobs processed, off-line time, and printing time. 65 

CPCONSOL also retrieves the stored log file to the screen 
for viewing and printing. The log file is in reverse chrono- 



Data 



Description 



STD 


<DaysxPagesxJobsxOffline> 


daily 




<Printing> 


statistics 


STC 


<DaysxPagesxJob5xOHline> 


cumulative 




<Printing> 


statistics 


STA 


<DaysxPagesxJobsx051ine> 


average 




<Printing> 


statistics 


SOJ 


<ApplicationxUserxJob> 


start of 




<File scrverxQueuexForm> 


job 


INI 


<NEB TypexROM/MAC Address> 


Initializa- 




<Printer Name> 


tion record 


POW 


<NEB TypexROM/MAC Address> 


power on 




<Printer Name> 


record 


RBT 


<NEB TypexROM/MAC Address> 


reboot 




<Printer Name> 


record 


WAR 


<Applicati onxWanring> 


warning 


EOJ 


<Appb'can' onxllserxjob> 


end of job 




<Disposition> 




ERR 


<ApplicationxError> 


error 



[Application Control (Step S1514)] 

Application control allows CPCONSOL to view the cur- 
rent configuration of the NEB within the network (as either 
CPSERVER or CRPR1NTER) (Step S1515) and to activate/ 
deactivate or modify and store that application (Step S1516). 
Access to the targeted NEB is provided via the LAN 
interface which responds to the CPCONSOL request by 
putting a result code on the LAN interface. 
[Printer Status (Step S1517)] 

This menu allows CPCONSOL to display the current 
status of the printer attached to the NEB (Step S1518), and 
to modify and store the new printer status (Step S1519). 
CPCONSOL directs a status request to the targeted NEB via 
the LAN interface. At the targeted NEB, CPSOCKET 
receives the status request and sends a request for the needed 
status information to the printer via the bi-directional SCSI 
interface. CPSOCKET receives the status information from 
the printer over the bi-directional SCSI interface and directs 
the information back to CPCONSOL where it is displayed 
on the system administrator's PC 14. 

There are 29 possible status conditions, "NORMAL" 
being the most common, as summarized in Tkble 8. 



TABLE 8 



Status 


Meaning 


NORMAL 


On-line, ready to print or 




printing 


OFFLINE 


Off-line, not ready to print 


ENGINETEST 


Engine test detected 


MAINTRUNNTNG 


Maintenance program running 


PAPEROUT 


Paper tray is empty 


PRINTEROPEN 


The printer top is open 


PAPER! AM x 


Paper, is jammed at location 
"x" 


NOEPCART 


No EP cartridge is present 


TONERLOW 


The toner cartridge is low 


ULFEED 


U-Lfeed 


LOADx 


Your paper is loading 


LOADnn 


Load paper "nn M 


FEED* 


Feed Paper [x=message) 


FEEDnn 


Feed paper "nn" 


OCx 


CaPSL output call 




ln=message] 


SETUPPER 


Set to upper tray 


TRAYFULL 


Paper output tray is full 


PAGEFULL 


The page is full 
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TABLE 8-continued 



Status 


Meaning 


I TNTPFRRfYR^ 

LMV LXivKUIUt 


22 line error (sec printer 




manual) 


LINEERROR40 


40 line error (sec printer 




manual) 


DLMEMORYFULL 


Download memory full 


WKMEMORYFULL 


Working memory full 


JOBREJECT . 


Job has been rejected 


PRINTCHECK 


Print check error 


OPTREMOVAL 


Option removal 


FONTFULL 


Font configuration are full 


WARMINGUP 


Printer is in warmup 


SERVICE CALL 


Service call is needed 


TRANSIENT 


A transient, unidentified 




error occurred 



10 



15 



4j. NEB Responses To Status Inquiry Using CPSOCKET 
CPSOCKET is an application program which runs out of 
DRAM 220 on the NEB 2 in the multi-tasking soft-time 
environment provided by the non-preemptive MONITOR. 20 
CPSOCKET causes SAPSERVER to monitor the NEB's 
broadcast socket on the LAN for broadcasts from client 
programs such as CPINIT, CPCONSOL and DOWN- 
LOADER. 

CPSOCKET is responsible for the internal configuration 25 
of the NEB, such as configuration as either a PSERVER or 
an RPRINTER. Configurations are set at the request of 
CPINTT, as described above, but it is CPSOCKET that 
receives those configuration commands and physically alters 
NVRAM 228. 30 

CPSOCKET also maintains a table of default settings for 
the device environment (that is, a guaranteed safe environ- 
ment, see section 4m below), downloads the basic configu- 
ration information for the printer and for the NEB (for 
example, fonts and emulations) at device power-up (see 35 
section 4d above), provides device status information, sta- 
tistics, and log information in response to CPCONSOL 
requests, and provides reset, re -boot, and firmware down- 
load capabilities. 

FIGS. 16 A and 16B comprise a detailed flow diagram 40 
showing operation of the CPSOCKET program. In Step 
S1601, after successful powcr-on-self-test (POST), micro- 
processor 216 transfers the CPSOCKET program module 
from its storage locations in EPROM 222 into appropriate 
storage locations in DRAM 220. During transfer, micropro- 45 
cessor 216 configures the CPSOCKET program in accor- 
dance with the configuration information for the 
CPSOCKET program stored in NVRAM 228. Tims, for 
example, it is possible to selectively activate certain portions 
of the CPSOCKET program module in accordance with 50 
desired levels of complexity, those desired levels of com- 
plexity being stored in NVRAM 228. 

In Step S1602, the NEB commences execution of the 
CPSOCKET from DRAM 220. CPSOCKET is executed in 
a multi-tasking soft-time environment by the non-preemp- 55 
tive MONITOR which permits non-preemptive execution of 
other application programs such as CPSERVER without 
letting one application program seize control of the micro- 
processor to the exclusion of other application programs. 

In Step S1603, CPSOCKET broadcasts its existence over 60 
the LAN interface via service advertising protocol broad- 
casts (SAPSERVER) which contain a proprietary socket 
number (sec sectoin 4g above). Because other servers are 
operating in the multi-tasking environment established in 
Step SI 602, and because the NetwareO-compatible software 65 
only permits a single non-fileserver server to advertise from 
a single network node such as the NEB, CPSOCKET 
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broadcasts its SAP advertisements via the SAPSERVER 
program. As described more fully above in paragraph 4g, the 
SAPSERVER program permits two network servers to 
broadcast from a single network node even when the net- 
work supports only single servers for each network node. 

In Step S1604, CPSOCKET receives a broadcast request 
from a client, for example, CPINIT or CPCONSOL on 
proprietary socket 453. CPSOCKET responds to the client 
(Step S1605) with an IPX packet on the same socket. 

In Step S1606, the client establishes direct SPX commu- 
nication with CPSOCKET over a socket number that is 
pre-assigned to CPSOCKET, here socket number 83B4 for 
communication or 83B5 for connection. In accordance with 
that direct connection, CPSOCKET receives and interprets 
client requests and/or commands that are received over the 
LAN interface, monitors the status of the printer over the 
bi-directional SCSI interface, receives and sends status 
commands and/or inquiries to the printer via the bi-direc- 
tional SCSI interface, reconfigures the NEB and the NEB 
configuration parameters, and sends requested information 
to the client via the LAN interface. These steps are described 
more fully below in connection with Steps S1607 through 
S1620 of FIGS. 16A and 16B. 

In more detail, in Step S1607, if CPSOCKET detenrunes 
that a configuration command has been received, then flow 
advances to Step S1608 in which the configuration com- 
mands are executed and the result provided via the LAN to 
the client Configuration commands are listed in Table 9 and 
generally pertain to the configuration of the NEB board as 
either a CPSERVER or an CRPRINTER in accordance with 
configuration commands initiated by the CPINTT program. 

TABLE 9 
Configuration Commands 



Data 

(CPINIT -> Reference 
Command CPSOCKET) (CPSOCKET -> CPINIT) 



request for 


none 


current NEB settings 


current 




(CPSERVER/RPRINTER/ 


configuration 




LPR) 


reconfigure/ 


Desired 


new configuration 


decon figure 


Configuration 


confirmation 


activate/ 


none 


confirmation 


deactivate 






application 






reset 


none 


confirmation 


re-boot 


cone 


none 



If in Step S1609, CPSOCKET determines that a device 
information command has been received, then flow 
advances to Step S1610 in which those device, information 
commands are executed and the results provided to the LAN 
interface. In general, device information pertains to the 
interface, control status, font set and environmental settings 
of the printer 4 attached to NEB 2. Device information 
commands in Step S1610 permit reading printer device 
information, setting printer device information, reading 
default settings for that information, and resetting the default 
settings to desired values. Device information commands 
are detailed in Table 10. 
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TABLE 10 



Device Information Commands 



TABLE 10-continued 



Device Information Commands 



request for 
default 
control 
status 

request for 
default font 
status 
request for 
default 
layout status 
layout status 
request for 
default 
quality and 
common 
environment 
status 
request for 
default 
duplex status 
request for 
' default 
miscellaneous 
printer info 



set control 



set font 



set quality 
and common 
environment 
set duplex 

set 

miscellaneous 
printer info 



set default 



new printer 
control 

information for 
CPCONSOL "control" 
menu 

new printer layout 
(portroit/landscap 
c, etc.) 

new printer macros 



new printer duplex 
mode 

new miscellaneous 
printer info 
(collation, 
stapling, paper 
hold, paper troys, 
etc.) 

default printer 





Data 


Response 


5 




Data 


Response 




(CPCONSOL -> 


(CPSOCKET -> 






(CPCONSOL -> 


(CPSOCKET -> 


Command 


CPSOCKET) 


CPCONSOL) 




Command 


CPSOCKET) 


CPCONSOL) 


request for 


none 


interface status 




control 


control 




interface 










information for 




status 






10 




CPCONSOL "control" 




request for 


none 


printer control 




menu 




control 




information for 




set default 


default printer 


confirmation 


status 




CPCONSOL 
"control" menu 




layout 


layout (portrait/ 
landscape, etc.). 




request for 


none 


printer font set 




set default 


default printer 


confirmation 


font status 






15 


quality and 


macros 




request for 


none 


printer layout 


common 






layout status 




(portrait/1 andsca 




environment 










pc, etc.) 




set default 


default printer 


confirmation 


request for 


none 


printer macros 




duplex 


duplex mode 




quality and 








set default 


default 


confirmation 


common 






20 


miscellaneous 


miscellaneous 




environment 






printer info 


printer info 




status 










(collation, 




request for 


none 


printer duplex 






stapling, paper 




duplex status 




mode 






holding, paper 




request for 


none 


rnisccDaneous 






trays, etc.) 




miscellaneous 




printer info 











(collation, 
stapling, paper 
folding, paper 
trays, etc.) 
default printer 
control 

information for 
CPCONSOL 
"control" menu 
default printer 
font set 

default printer 
layout 
(portrait/ 
landscape, etc.) 
default printer 



default printer 
duplex mode 

default 

miscellaneous 
printer info 
(collation, 
stapling, paper 
folding, paper 
trays, etc.) 
confirmation 



confirmation 

confirmation 

confirmation 
confirmation 



confirmation 
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If in Step S1611, CPSOCKET determines that a configu- 
ration parameter command has been received, then flow 
advances to Step S1612 in which CPSOCKET executes the 
received command and provides the result via the LAN to 
the client. As shown in Table 11, configuration parameter 
commands pertain generally to parameter values stored in 
the NEB concerning time, date, safe printer environment 
information, logging options, log file size, etc. 



TABLE 11 



Configuration Parameter Commands 





Data 






(CPINTT -> 


Response 


Command 


CPSOCKET) 


(CPSOCKET -> CPtNTT) 


request for 


none 


configuration 


current 




parameters (e.g. 


configuration 




time, dam, safe 


parameters 




printer environment 






info, logging 






options, etc) 


set new 


configuration 


confirmation 


configuration 


parameters (e.g. 




parameters 


time, data, safe 






printer environment 






info, logging 






options, etc.) 





If in Step S1613 CPSOCKET determines that a NEB 
application program command has been received, then flow 
advances to Step S1614 in which CPSOCKET provides 
information on the current application program, namely 
RPRINTER, PSERVER, or LPR (for UNIX). Application 
program information generally includes server name, file 
server queue, device ID, etc., as detailed in Table 12. 



TABLE 12 



60 



Application Program Information 



Command 



Data 

(CPTNTT -» 
CPSOCKET) 



Response 
(CPSOCKET - 
CPINIT) 



65 request for 

CRPR1NTER info 



none 



CRPRINTER 
info 
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TABLE 12-continued 



44 



Application Program Information 





Data 


Response 




(CPINIT -» 


(CPSOCKET -> 


Command 


CPSOCKET) 


CPINIT) 


set CRPR INTER 


new CRPRINTER info 


confirmation 


info 






request for 


none 


CPSERVER info 


CPSERVER info 






set CPSERVER 


new CPSERVER info 


confirmation 


info 






request for 


none \ 


CLPR info 


CLPR info 






set CLPR info 


new CLPR info 


confirmation 



If in Step S1615 (FIG. 16B) CPSOCKET determined that 
a NEB/printer statistic command has been issued, then flow 
advances to Step S1616 in which CPSOCKET interrogates 
the printer through the bi-directional SCSI interface to 
obtain needed printer statistics. The statistics correspond to 
the network group displays described above in connection 
with CPCONSOL, as well as to print job statistics such as 
the total number of pages printed, the total number of jobs, 
the total number of off-line time, etc. The job statistics 
correspond to the logging group described above in connec- 
tion with the CPCONSOL program. Specific examples of 
the commands executed in the NEB/printer statistics com- 
mands are set forth in Table 13. 



20 



25 



TABLE 13 





Statistics Commands 




Data 






(CPCONSOL -> 


Response 


Command 


CPSOCKET) 


(CPSOCKET -> CPCONSOL) 


request 


none 


network statistics 


network 




for CPCONSOL 


statistics 




"NETWORK" menu 


clear 


none 


confirmation 


network 






statistics 






request job 


none 


job statistics for 


statistics 




CPCONSOL "LOGGING" 






menu 


clear job 


none 


confirmation 


statistics 







If in Step S1617 CPSOCKET deterrnines that a logging 
command has been received, then flow advances to Step 
S1618 in which CPSOCKET obtains the log file from the 
printer disk 114 via the bi-directional SCSI interface, and 
sends the log file to the client via the LAN interface. 
Logging commands are summarized Table 14. 

TABLE 14 



Command 


Logging Commands 
Data 

(CPCONSOL -> Response 
CPSOCKET) (CPSOCKET -> CPCONSOL) 


request 


block # 


next block number of 


log file 




log file and log data 


clear log 


none 


confirmation 


request 
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able code and storing it in specified locations in DRAM 220, 
by providing check-sum data for the downloadable code, 
and by flashing the downloadable code into EPROM 222. 
Some of the more important download commands are sum- 
marized in Table 15. 

TABLE 15 



60 



If in Step S1619 CPSOCKET determines that a download 
command has been received from the LAN interface, then 65 
flow advances to Step S1620 in which CPSOCKET executes 
the download request, for example, by receiving download- 



Command 


Download Commands 
Data 

(DOWNLOAD ~> 
CPSOCKET) 


Response 
(CPSOCKET -» 
DOWNLOAD) 


download 


code 


confirmation 


request 






call request 


checksum, 


confirmation 




starting address 




flash EPROM 


checksum 


confirmation 



4k. Logging Peripheral Statistics 

As described earlier with respect to FIG. 5A, Steps S9 
through S12 comprise an automatic logging function in 
which peripheral statistics (e.g. number of pages printed per 
day) and error events are automatically logged (stored) for 
later retrieval; and wherein the logging level (statistical 
resolution) may be varied by the network administrator. In 
general, the network administrator may select a logging 
level, and then extract printer statistics and error events from 
the log file at any time. The network administrator's portion 
of such functions has been described above in paragraph 4i T 
and reference may be had to the discussion and tables set 
forth therein, especially Table 7 which indicates the content 
of the log file depending upon the logging level set by 
CPINIT. 

As background, few LAN peripherals maintain their own 
statistics, but the NEB 2 includes the capability of logging 
the current status and daily statistics of printer 4 at rmdnight 
of each day. This relieves the system administrator from 
having to remember to do this on a daily basis. The status 
and statistics data may be stored in printer hard disk 114, 
printer NVRAM 111, NEB DRAM 220, or in the NEB 
NVRAM 228. The location of the stored log file may be 
selected by the network administrator depending upon the 
remaining memory capacity of each of those memories, and 
the statistics required by the logging level selected by the 
network administrator. For example, if the printer has a hard 
disk, the network administrator may choose the fairly- 
detailed "JOB", logging level so that voluminous statistics 
may be retained On the other hand, if the printer has no hard 
disk, the network administrator may choose the less-detailed 
"ERROR" logging level so that less storage space is 
required. If the log file is filled, new error data will merely 
wrap around in the memory replacing old error data with 
new error data. 

The NEB will automatically store printer statistics such as 
pages printed, jobs printed, off-line time, and print time each 
night for access for the system administrator at a later time. 
The statistics can be used to anticipate replacement of 
consumable printer supplies, such as toner, and to monitor 
user behavior such as leaving the printer off-line for 
extended periods of time. 

In general, the logging function is accomplished by the 
printer controller board always knowing what time it is. 
When a printer/controller board is first powered on, the 
board finds the nearest server and requests the time. The 
board continues to do this every minute. When the day of the 
week changes, the board automatically requests the printer 
to report its page count. The board then calculates the daily 
statistics and stores them either to the printer hard disk or to 
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the board NVRAM. These statistics are stored and available 
to the external network program CPCONSOL that can 
display them to a screen or save them to an external file. 

As described above in paragraph 4i, the network admin- 
istrator may select four logging levels: NONE; AUTO; 5 
ERROR; and JOB. At the NONE level, no logging statistics 
are maintained (although they may still be calculated every 
minute and temproarily kept in NEB DRAM 220). At the 
AUTO level, daily statistics are maintained for printer 
features such as printing days, pages, jobs, off-line time, and 10 
print time. The number of cumulative pages printed is 
determined by the printer, but the other statistics are deter- 
mined by the NEB. 

The ERROR logging level maintains the daily statistics 
discussed above, and also error conditions in the printer and 15 
also errors that occur in an application (i.e. CPSERVER). 
The NEB queries the printer every minute for such error 
conditions. Such printer error conditions may include: off- 
line; out-of-paper; printer-is-open; paper-jam; no-toner-car- 
tridge; toner-is-low; printer feed and load errors; tray-is-full; 20 
line errors; print-job-rejected; font-is- full; service call; etc. 
Application errors may include: fileserver down; primary 
fileserver unavailable; CPSERVER running elsewhere; IPX 
not installed; etc. 

The JOB logging level maintains the daily statistics and 25 
error conditions noted above and also maintains job start and 
job end information, which are determined by the NEB. Of 
course, the number and types of logging levels, and the data 
retained in each logging level may be varied according to the 
particular peripheral and the particular LAN in which the 30 
NEB is installed. 

FIGS. 17A and 17B comprise a flow chart showing the 
overall operation of the automatic logging function within 
the NEB. Reference may also be had to FIG. 5A and Table 
7 noted above. At Step SI, power is applied to the NEB and 35 
at Step S8, the timer module finds the nearest server and 
requests the time. At Step S1701, it is determined whether 
the NONE logging level has been selected. If the NONE 
logging level has been selected, the process skips to the end . 
of the flowchart where a return is made to the overall flow 40 
diagram of FIGS. 5A, 5B and 5C. 

If the NONE logging level has not been chosen in Step 
S1701, Step S1702 determines whether the AUTO logging 
level has been selected. If the AUTO logging level has been 
selected, the process proceeds to Step S9 where midnight is 45 
awaited. However, if the AUTO logging level has not been 
selected, Step S1703 determines whether the ERROR log- 
ging level has been selected. Where the ERROR logging 
level has been selected, the process skips to Step S1706 
where a one minute timeout is awaited. However, if the 50 
ERROR logging level has not been selected, it is determined 
in Step S1704 that the JOB logging level has been selected. 
In this case, Step S1705 stores the job start and job end times 
to the log file. At Step S1706, a one minute timeout is 
awaited whereafter Step S1707 queries the printer for error 55 
events and saves such events to the log file. Thus, when 
either the ERROR or JOB logging levels have been selected, 
the board queries the printer every minute for error events 
and stores such error events in the log file. 

Step S9 waits for midnight whereupon the NEB queries 60 
the printer for its daily statistics at Step S10 FIG. 1SB). If 
midnight has not been reached in Step S9, the procedure 
returns to Step S1702 where it is determined which logging 
level has been selected. 

In Step Sll, the daily printer statistics are calculated 65 
utilizing the printer statistics received in Step S10. There- 
after, in Step S12, the daily statistics and the error events are 
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stored in the printer hard disk 114 and/or the printer 
NVRAM 111, and/or the NEB NVRAM 228. Note here that 
the network administrator may select to store logging sta- 
tistics and error events in any combination of memories, 
providing further flexibility to the LAN. 

The logging functions discussed above are quite signifi- 
cant in making the printer an interactive and responsive 
member of the LAN since the SCSI connection between the 
NEB and the printer is capable of extracting volumes of 
specific data from the printer. 
41. Multi-tasking Independendy Executable Programs 

As briefly described earlier with respect to Step S20 of 
FIG. 5B, the NEB EPROM 222 stores a MONITOR pro- 
gram which is a mechanism which supports multi-tasking in 
the run-time environment while permitting synchronous 
operation in a de-bug environment. MONITOR permits 
currendy-called tasks to be performed on a non-preemptive 
basis while the NEB awaits real-time interrupts from either 
the LAN (for CPSERVER or CPSOCKET) or through the 
SCSI interface (e.g., when status information is being pro- 
vided from the printer to the NEB in response to a previ- 
ously-received status request from the LAN). Thus, MONI- 
TOR permits all currently-executing tasks to be performed 
simultaneously by sharing use of the microprocessor 216. Of 
course, all soft-time applications, including MONITOR 
itself, are interruptable by real-time events. 

FIG. 18 is a notional flowchart of a sequence of events 
which may occur in order to illustrate the multi-tasking 
operation within the NEB. At Step SI, power is applied to 
the NEB, and the MONITOR program is downloaded from 
EPROM 222 to DRAM 220 in Step S1801, For example, the 
following modules are downloaded together with MONI- 
TOR: SCSI Driver, Link Support Layer; Network Driver; 
Prescan; IPX/SPX; Customized NETX; SAPSERVER; 
CPSOCKET; and Print Applications (see FIG. 6). 

If, at Step S1802, print data is received from file server 30, 
CPSERVER will begin processing the received job data in 
preparation for transmission to the printer 4. Processing of 
such print information is now in the "soft-time" environ- 
ment, and Step S1803 determines whether a relinquish 
interrupt has been received from the program processing the 
print data. If a relinquish interrupt has been reached at Step 
S1803, execution of the currently-executing module is 
stopped and control is returned to MONITOR at Step S1804. 
MONITOR saves the state of the interrupted task in DRAM 
220. However, if the relinquish interrupt has not been 
reached at Step S1803, the process proceeds to Step S1805 
where it is determined whether the currently-executing 
module has reached an end. If the end has not been reached 
in Step S1805, the program waits until another relinquish 
interrupt is reached in Step S1803. 

If the currently-executing module has been stopped at 
Step S1804, or if the currently-executing module has 
reached an end at Step 5 1805, it is determined at Step S1806 
whether data has been received which requires the execution 
of another software module, e.g., where data is received over 
the SCSI interface in response to a previously-issued request 
for printer status. If it is determined in Step S1806 that such 
data has been received, Step S1807 begins execution of 
another application module using the newly-received data. 

At Step 1808, it is determined whether a relinquish 
interrupt has been reached in the second application module. 
If such an interrupt has been reached, the second application 
will stop execution and pass control to MONITOR which 
stores in DRAM 220 the state of the just-interrupted second 
module at Step S1809. However, if the relinquish interrupt 
in the second module has not been reached at Step S1808, 
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it is determined at Step S1810 whether the end of the second 
module has been reached. If the end has not been reached, 
the program merely awaits the relinquish interrupt at Step 
S1808. If it is determined that the second module end has 
been reached in Step S1810, Step S1811 determines whether 5 
the first module end has been reached. Where the end of the 
first module has not been reached, but the end of the second 
module has been reached, the process returns to waiting for 
a relinquish interrupt in the first application module at Step 
SI 803. If both the first and second modules have reached 10 
their end at Step S1811, control will return to the MONITOR 
program in order to execute other newly-received soft-time 
tasks. 

After the second application module has stopped execut- 
ing due to reaching a relinquish interrupt therein, control is 15 
passed to MONITOR which, after storing the state of the 
interrupted module in DRAM 220 (Step S1809), will recom- 
mence execution of the first module in Step S1812, and 
continue execution of the first module until another first 
module relinquish interrupt is reached at Step S1803. 20 

Thus, the non-preemptive multi-tasking allocation of the 
microprocessor resources allows processing of a number of 
tasks in parallel on a near real-time basis. 
4m. Placing The Printer In A Default Configuration 

As discussed above with respect to Step S25 in FIG. 5C, 25 
the NEB will ensure that the printer is set to a known, default 
configuration at the beginning or end of a print job. The NEB 
does this by downloading to the printer's non- volatile 
memory (either hard disk 114 or NVRAM 111) a default 
configuration code which indicates the default environment 30 
(e.g. portrait mode, 10 point type, Roman lettering, etc.) in 
which the printer should be left at the conclusion of a print 
job. Upon receiving a print data stream from the LAN, the 
NEB retrieves the configuration code from the printer's 
non-volatile memory, appends the configuration code to a 35 
block of print data as an escape sequence, and then down- 
loads the print job block with appended escape sequence to 
the printer. The printer will then conduct a printing opera- 
tion, and (based on the escape sequence) will leave the 
printer in the desired default configuration. 40 

Novell NetWare© software includes the ability to reset a 
network printer in a default environment after every print 
job. It does this by having the file server 30 install what 
amounts to a fake print job at the head of the print job itself. 
However, the exact printer escape sequences necessary to set 45 
particular printer default configurations reside in a database 
on the network, and not within the printer itself. Therefore, 
if it is desired to operate UNIX on the LAN, or where there 
is a problem with the file server itself, the printer may not be 
restored to a default configuration which ensures that the 50 
next print job will be printed with the printer in a known 
configuration. 

A method of guaranteeing a printer default environment 
using the NEB operates on the difference that the printer 
reset state configuration and requisite escape sequence 55 
instructions reside within the printer itself, and the printer 
itself is responsible for resetting its own environment within 
print jobs. Thus, the printer reset feature is available without 
depending upon any device external to the printer. Further- 
more, the initial default configuration may be loaded and 60 
subsequently modified from a remote location over the LAN 
through the NEB's serial or parallel interfaces. 

The configuration code may be sent to the NEB through 
the CPCONSOL program, as discussed above in section 4i. 

It may be convenient to store a plurality of default 65 
configuration codes in the printer non-volatile memory in 
order to allow the network administrator great flexibility for 
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printer usage on the LAN. For example, print jobs received 
from an engineering source may require the printer to 
default to a portrait mode, whereas print jobs received from 
accounting may require that the printer be left in a spread 
sheet mode. Thus, by ensuring a known default environ- 
ment, any of a number of LAN sources may utilize the 
printer for their specific jobs. 

FIG. 19 depicts a more detailed flowchart for setting the 
printer default configuration. At Step SI, power is applied to 
the NEB, and at Step S22, the NEB accesses the LAN file 
server for active print queues and downloads print data to the 
DRAM 220. 

If the printer non-volatile memory stores more than one 
default configuration code, it may be necessary to first 
determine what type of data is being transmitted from the 
LAN in order to determine which default configuration the 
printer should be left in. Therefore, Step S9101 determines 
the LAN source of the print job, and Step S1902 retrieves the 
appropriate default configuration code from the printer, 
which code corresponds to the determined LAN source. 

At Step S1903, the NEB assembles blocks of image data 
and designates a start-of-print-job and an end-of-print-job 
for each print job. At Step S1904, the NEB microprocessor 
216 appends to a print job an escape sequence which 
corresponds to the retrieved configuration code. Preferably, 
the escape sequence is appended to the beginning of the print 
job, but it may be appended to the end of the print job, or to 
both the beginning and end of the job. Then, at Step S1905, 
the print job, with appended escape sequence, is transferred 
to the printer, and the printer then renders print according to 
the received print job. When a print job is completed after 
Step S24, the printer will set itself to a default environment 
at Step S25, which environment corresponds to the default 
configuration code retrieved in Step S1902. Therefore, the 
printer will be left in a default environment which ensures 
that the next print job will begin with the printer in a known 
configuration. 

Thus, a robust and efficient hardware and software solu- 
tion has been found for ensuring that the printer itself stores 
a default configuration and is responsible for placing itself in 
a default condition at the end of every print job. 
4n. Downloading Executable Files Into The NEB From A 
Remote Location 

The downloading of executable files from the LAN to 
DRAM 220 will be discussed in more detail with respect to 
the flow diagram in FIG. 20, and with respect to the 
discussion above of Step S30 in FIG. 5C. 

NEB 2 is configured initially prior to shipping. However, 
NEB 2 can be reconfigured subsequently by sending updated 
executable files across the LAN from the network adminis- 
trator's PC 14 to the NEB 2. Furthermore, network admin- 
istrator can remotely alter the executable files stored in 
DRAM 220 of NEB 2, as desired. 

The process by which executable files can be altered in 
DRAM 220 will be discussed in detail with respect to FIG. 
20. 

After the board has been powered-up at Step SI, the flow 
proceeds to Step S2001 at which point the network admin- 
istrator activates a DOWNLOADER program to broadcast 
over the LAN a request for identification of all NEB devices 
having a particular configuration whereupon flow advances 
to Step S2002. 

In Step S2002, the DOWNLOAD program determines 
whether any target NEBs have responded. If in Step S2002 
it is determined that no target NEBs have responded, flow 
returns to Step S2001 in which the DOWNLOAD program 
rebroadcasts the request with new target information and 
then flow advances to Step S2002. 
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If in Step S2002 a target NEB responds, flow advances to 
Step S2003. 

In Step S2003, the SAPSERVER program responds with 
the unique network IDs and the unique socket numbers 
assigned to each NEB (see secdon 4g above). This location 
information is collected, the network administrator selects a 
particular NEB to download an executable file, and com- 
munication is established with the target NEB. 

Upon selecting the target NEB, the network administrator 
downloads new operational files and a spetial packet con- 
taining a checksum value to DRAM 220 across the LAN in 
Step S2004 whereupon flow advances to Step S2005. 

In Step S2005, microprocessor 216 performs a checksum 
operation on the newly loaded operational files and com- 
pares the checksum value with a checksum value sent in the 
special packet which is stored in DRAM 220 after the 
operational files have been stored. 

If the checksum value docs not equal the checksum value 
in the special packet, then Mow advances to Step S2006 at 
which point microprocessor 216 notifies the network admin- 
istrator that the checksum value for the new operational files 
is incorrect and at which point microprocessor 216 may 
purge the files from DRAM 220. 

If in Step S2006 the checksum value is verified, then flow 
advances to Step S2007 at which point the executable files 
are acted on by microprocessor 216. 

Thus, the network administrator can alter the operation of 
NEB 2 by remotely sending new operational files to be 
stored and to be executed from DRAM 220. 
4o. Loading Independently Executable Modules In ROM 

As described above in FIG. 5C with respect to Step S32, 
when a binary ROM image is to be loaded into EPROM 222, 
a plurality of indepcndcntiy-cxecutable modules are 
assembled, ordered, and prepared for flash to EPROM 222. 
The assembly and ordering of the modules is presently 
carried out on a DOS PC, but may be carried out in the NEB 
itself. An advantage of assembling the independently 
executable modules in a PC is that the modules may be 
constructed and/or modified in a DOS environment. 

NEB firmware comprises a number of separately linked 
modules, one of which contains permanently ROM-resident 
code which receives control at power-up and provides 
self-test, loading of other modules into DRAM 220, and 
basic I/O services. The other modules residing in the 
EPROM 222 must be copied to DRAM 220 before execu- 
tion. There are two types of such modules, the first of which 45 
includes programs which are essentially drivers which 
receive control when loaded, initialize, and then exit, 
remaining resident. The second type of such modules are 
application programs, each of which executes a specific set 
of functions. 

In FIG. 21, the NEB is powered-up at Step SI. At Step 
S2101, a utility resident in the PC reads from its RAM a 
configuration file containing the names of all modules to be 
placed in the ROM image. The configuration file is used to 
select from RAM, at Step S2102, those modules which are 
going to be flashed to EPROM 222. 

At Step S2103, the utility writes a header for the first 
module, the header identifying that module, describing the 
module attributes, and including a pointer which points to 
the immediately succeeding module. This pointer aides in 
the ordering of the modules in a specific order prior to 
loading. At Step S2104, it is determined whether the last 
module identified by the configuration file has been selected. 
If the last module has not been selected, the process loops to 
Step S2103, where the header is written for the next module. 

When the last module has been selected in Step S2104, 
the utility appends the ROM-resident code to the end of the 
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image program (at Step S2105) so that upon power-up, the 
initialization code resides at the address expected by micro- 
processor 216. 

When the ROM binary image is thus constructed, the 
image may be downloaded to one portion of the memory 
area of NEB DRAM 220, and then flashed to EPROM 222, 
as will be discussed in greater detail in section 4q below and 
with respect to the detailed discussion of FIG. 5C, Step S36. 
4p. Protecting The EPROM During A Flash operation 

FIG. 22 is a block diagram showing the functional con- 
struction of the EPROM flash protection circuitry resident 
on the NEB. The EPROM flash protection circuit includes 
microprocessor 216 coupled to data bus 250 and address bus 

251. Also connected to data bus 250 and address bus 251 is 
DRAM 220. DRAM 220 is capable of storing a ROM 
firmware image downloaded from a remote LAN device into 
one portion of its memory area (see section 4o above), and 
application process steps into another portion of its memory 
area. Also coupled to data bus 250 and address bus 251 are 
EPROM 222, latch 252, and PAL 253. D-type flip-flop 254 
is connected to latch 252 and PAL 253. During operation, 
flip-flop 254 receives as its clock input an output signal from 
PAL 253 and as its data input, an output signal from latch 

252. Latch 252 and PAL 253 are also connected to DC-DC 
converter 212, and DC-DC converter 212 is connected to 
transistor switch 255. When activated by latch 252, DC-DC 
converter 212 sends +12 volts to the input emitter of 
transistor switch 255. Flip-flop 254 is also connected to 
transistor switch 255 to provide the necessary input to 
open/close switch 255. 

The operation of the EPROM flash protect circuitry will 
now be explained in more detail with reference to FIG. 22. 
Upon power-up, output of latch 252 will be low and flip-flop 
254 will be reset. In this manner, the output signal PROG1 
from latch 252 will be low and voltage from DC-DC 
converter 212 will be directed to sink current to a ground 
state. At power-up, flip-flop 254 is reset so that its output is 
set low thereby opening transistor switch 255. 

With transistor switch 255 in an open state, Vpp pin of 
EPROM 222 will be held at 0 volts preventing any data from 
being accepted or a flash operation from being performed. 
That is, for a flash operation to occur in EPROM 222, the 
Vpp pin must reach a level of at least +1 1.4 volts, which is 
a requirement set by the EPROM manufacturer's specifica- 
tions. However, in order to achieve this voltage level, the 
following two programming steps are required. 

First, when a new ROM firmware package is received in 
DRAM 220, microprocessor 216 receives a command to 
flash EPROM 222, by generating an I/O write to address 360 
hex with data bit 7 high (80 hex). In this manner, DC-DC 
converter 212 can be first turned on. 

As shown in Tables 16 and 17, address 360 hex corre- 
sponds to control register 230 which is used to control 
read/write operations to NVRAM 228. As shown in Table 17 
below, when 360 hex is sent with bit 7 high/low, the address 
corresponds to an operation of DC-DC converter 212. 

TABLE 16 



60 



65 



I/O SELECT 



ADDRESS 



LAN CHIP 
DMA DATA LATCH 
LAN CHIP SOFT RESET 
SCSI CHIP REGISTER 
STATUS REGISTER 
CONTROL REGISTER #1 
CONTROL REGISTER #2 



300-3OFHEX(R/W) 
310 - 317 HEX (R/W) 
318-31FHEX(R) 
320 - 32B HEX (R/W) 
330 HEX (R) 
360 HEX (R/W) 
366 HEX (X) 
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TABLE 16-continued 



1/0 SELECT 


ADDRESS 




NMILCK 


200 HEX (W) 


5 


LAN ADDR. ROM. 


340 - 35F (R) 




TABLE 17 



MSB LSB 
|7|6|S|4|3|2|lT0l 



NVRAM CS (WRITE), DO (READ) 

NVRAM SK(WRITE) 

NVRAM DI (WRITE) 

NOT USED 15 

NOT USED 

NOT USED 

DIAG.LED l=ON 

0=OFF 

+12V DC CONVERTER 

l=ON 20 
0=SHUTDOWN 



After address 360 hex is output, microprocessor 216 
generates an I/O write command and sends a write select to 
PAL 253. PAL 253 detects a valid address, decodes it and 
activates latch 252. With bit 7 high in address 360 hex, the 
PROG1 signal is set high and output from latch 252 to 
DC-DC converter 212. When the PROG1 signal is received 
at DC-DC converter 212, it operates DC-DC converter to 
produce +12 volts. The +12 volts from DC-DC converter 
212 is sent to transistor switch 255, and which remains at its 30 
emitter until transistor switch 255 is closed. 

However, before +12 volts is allowed to pass through 
transistor switch 255, the second step must be executed. That 
is, microprocessor 216 outputs an I/O read command and 
outputs address 366 hex which corresponds to a PAL 35 
address. When microprocessor 216 generates both the com- 
mand and address, PAL 253 decodes the address and gen- 
crates a PROG2 signal. When the PROG2 signal is high, it 
will provide a clock input to flip-flop 254. 

Upon receiving the clock input, flip-flop 254 will input the 40 
PROG1 signal from latch 252 and then generate a TRAN- 
SON signal at its output. TheTRANSON signal is output to 
transistor switch 255 which operates to close the switch that 
allows +12 volts at its emitter to pass through to its collector. 
At this point, +1 2 volts is sent from the collector of transistor 45 
switch 255 to the Vpp pin of EPROM 222. 

With +12 volts placed at the Vpp pin of EPROM 222, 
microprocessor 216 sends out an EPROM select signal. In 
order to prevent the new firmware image from being cor- 
rupted, EPROM 222 must first be cleared and erased. Then 50 
the EPROM 222 is flashed with the new ROM firmware 
image stored in DRAM 220. Once the new ROM firmware 
image is stored in EPROM 222, NEB 2 can be re-booted 
from the new ROM firmware image. 

The operation of the EPROM protection circuit will now 55 
be explained with reference to FIG. 22 and the flowchart of 
FIG. 23. 

In Step S2301, a new ROM firmware image is received by 
NEB 2 across the LAN and loaded into DRAM 220. 
Microprocessor 216 receives a command to flash EPROM 60 
222 in Step S2302. In Step S2303, microprocessor 216 sends 
out an I/O write command to PAL 253 and outputs address 
360 hex with bit 7 high. Flow advances to Step S2304 in 
which bit 7 high activates latch 252 to output the PROG1 
signal. The PROG1 signal turns on DC-DC converter 212 65 
and +12 volts is output to transitor switch 255. In Step 
S2305, microprocessor 216 sends both an I/O read cora- 
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maud to PAL 253 and address 366 which is a PAL address. 
In response, PAL 253 outputs the PROG2 signal to clock 
flip-flop 254 which allows the PROG1 signal to be input at 
its data input. Flip-flop 254 outputs the TRANSON signal to 
transistor switch 255 which allows +12 volts to pass from 
the collector of transistor switch 255 to the Vpp pin of 
EPROM 222. In Step S2306, microprocessor 216 clears and 
then erases EPROM 222. In Step S2307, microprocessor 
216 determines if EPROM 222 has been completely erased. 
If EPROM 222 is not completely erased, flow returns to Step 
S2307. 

After microprocessor 216 determines that EPROM 222 
has been completely erased, in Step S2308, the ROM 
firmware image is downloaded from DRAM 220 to EPROM 
222. Once the ROM firmware image is successfully loaded, 
in Step S2309 microprocessor 216 writes address 360 hex 
with bit 7 low. The PROG1 signal from latch 252 goes low 
and DC-DC converter 212 allows the voltage level to sink 
current to a ground state. 

In Step S2310, microprocessor 216 sends PAL 253 an I/O 
read command and a 366 hex address which permits the 
PROG2 signal to go low thereby clocking the flip-flop which 
outputs a low TRANSON signal which operates to open 
transistor switch 255. 

Thus, in Steps S2309 and S2310, +12 volts is removed 
from Vpp pin of EPROM 222 and the flash operation is 
ended. After the flash operation, microprocessor 216 deter- 
mines if a re-boot command has been received in Step 
S2311. If the re-boot command has been received, NEB 2 is 
re-booted in Step S2312 from the new ROM firmware image 
in EPROM 222. However, if no re-boot command is 
received, then flow ends. 
4q. Remotely Altering Firmware 

The method for remotely altering firmware in EPROM 
222 will be discussed in more detail below and with refer- 
ence to the flowchart illustrated in FIG. 24, Step S36 of FIG. 
5C, and section 4i above. 

Prior to shipping a NEB to a customer, the NEB is 
configured with the minimum number of executable files 
which permit the NEB to perform necessary functions. 
However, the NEB can be reconfigured subsequently by the 
customer. That is, a network administrator may download 
data from a remote LAN device, which data may contain 
anything from a patch code, to manufacturing test routines, 
to entire firmware updates to be downloaded to the EPROM. 

In more detail, NEB2 can be reconfigured by sending 
executable files across the LAN from the network adminis- 
trator's PC 14 to NEB 2. The network administrator can 
remotely alter the ROM firmware image in EPROM 222, as 
desired. 

In Step S2401, the network administrator activates a 
CPFLASH program that uses a MAC address as a command 
line parameter to target a specific NEB. CPFLASH issues a 
SAP broadcast request which is responded to by SAPS- 
ERVER running on the NEB. In Step S2402, CPFLASH 
waits for a response from the targeted NEB. If in the case 
where the targeted NEB does not respond in approximately 
1 5 seconds, the flow returns to Step S2401 and the broadcast 
is resent. However, in the case where the targeted server 
responds, flow advances to Step S2403. 

In Step S2403, the address and location of the targeted 
NEB is received, communication with the NEB having the 
matching MAC address is established, and a new ROM 
image firmware is downloaded over the LAN to DRAM 220. 

In Step S2404, the validity of the ROM firmware image 
is checked before proceeding to the next step. The validity 
of the ROM firmware image is verified against an image 
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checksum which is sent in a special packet along with the 
download operation in Step S2403. If the checksum value 
does not match the checksum downloaded with the ROM 
image, then in Step S2405 the operator is notified of an error 
and the ROM firmware image in DRAM 220 is purged. 5 

If the checksum value is valid, then flow advances to Step 
S2406 at which point microprocessor 216 retrieves any data 
which is to be preserved, such as the MAC address, and 
stores the data within the proper locations in the new 
firmware image stored in DRAM 220. In this fashion, if the 1Q 
new ROM firmware image is defective, the NEB may still 
function since predetermined portions of essential ROM 
firmware arc maintained. Once the essential portions of 
ROM firmware are preserved, flow advances to Step S2407 
at which point EPROM 222 is controlled to be cleared and 
erased a plurality of times, if requried. After EPROM 222 15 
has been erased, in Step S2408 the new ROM image is 
loaded into EPROM 222. 

After the flash operation, microprocessor 216 determines 
if a re-boot command has been received in Step S2409. If the 
re-boot command has been received, NEB2 is re-booted in 20 
Step S2410. However, if no re-boot command is received, 
then flow ends. 

In Step S2404, the validity of the ROM firmware image 
may also be verified by comparing newly received firmware 
data with data previously stored in EPROM 222. For 25 
example, where EPROM 222 stores hardware indicators 
previously carried by PROM 232 (e.g., board manufacture 
dale, board revision number, manufacturing facility, etc.; to 
be discussed in greater detail in section 5 below), such 
indicators may be compared with the same indicators in the 30 
newly-received ROM firmware image. This comparison 
may be made in addition to or in lieu of the checksum 
comparison discussed above. 

It is noted that a new MAC address may also be flashed 
into EPROM 222 at the same time a ROM firmware image 35 
is flashed. However, it is preferable only to flash a MAC 
address prior to shipping, at the completion of NEB test. 
This feature is discussed in more detail with respect to 
Section 5 below. 

5. TEST 40 

Prior to installing the NEB in the printer, it may be tested 
to ensure the integrity of its hardware and software compo- 
nents. FIG. 25 depicts one test configuration which may be 
utilized to test the NEB 2. In FIG. 25,-the NEB 2 is coupled 
to PCI 300 via a cable 302 coupled to the NEB serial port 45 
218. A printer 304 may be coupled to PCI 300 in order to 
print out test results. 

The NEB 2 is coupled to a test driver PC2 306 through an 
SCSI bus 308 and Ethernet LAN connections 310, 312. The 
PC2 306 includes an SCSI board 314.and a network con- 50 
troller board 316 so that it may simulate a printer and LAN 
entities (such as the network administrator's PC 14). The 
PC2 will act as a transponder, receiving and returning 
communications to and from the NEB 2, as commanded by 
the test programs input to the NEB from PCI 300 through 55 
the serial port 218. 

After power is applied to NEB 2, it performs the power- 
on-self-test operation. While the NEB 2 is performing each 
test operation in the POST, PCI 300 receives test checkpoint 
results across serial cable 302. 60 

Once it is determined that NEB 2 has satisfactorily 
completed POST, NEB 2 enters a "Ready For Download" 
state. In this state, NEB 2 waits for a period interval of 
approximately one second for further input instructions 
across any one of the input ports. 65 

While the NEB is in the download state, PCI 300 uploads 
test programs to the NEB through serial port 218. As NEB 
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2 completes execution of each test program, it sends each 
test result back to PCI 300 for verification. If the next 
checkpoint is not received within a timeout period (e.g., 1 
second), it is determined that an error has occurred during 
the NEB test program, and an error signal is output by PCI 
300. The error signal may be indicated on a display at PCI 
300, or printed out on printer 304. 

on the other hand, if the next checkpoint received by PCI 
300 is not verified, then PCI 300 rescripts the test program 
(by adding further, more detailed test modules) in accor- 
dance with the received result In this manner, PCI 300 can 
locate the problem and debug NEB 2. 

Some test programs may require NEB 2 to communicate 
with PC2 306 over either the SCSI bus 308 or one of the 
LAN connections 310, 312. For instance, in accordance with 
the test program, NEB 2 may request data from PC2 over the 
LAN connection 310. PC2 306 is configured to return 
appropriate responses to each communication from NEB 2, 
thereby effectively emulating the printer and the other LAN 
members. If the correct communication is returned from 
PC2 306, NEB 2 indicates a successful test by passing 
another checkpoint to PCI 300 through the serial port 218. 

A more detailed discussion of the method for testing NEB 
2 will be provided below with reference to the flowchart 
illustrated in FIGS. 26 A and 26B, and in accordance with the 
test configuration depicted in FIG. 25. 

When power is first applied to the NEB 2, NEB 2 executes 
the POST program from EPROM 222, in Step S2601. The 
POST program includes individual programs for testing 
component operation and software programming. After 
execution of an individual programs within POST, in Step 
S2602 a checkpoint is sent to PCI 300 to be verified. If a 
checkpoint is not sent after a predetermined period follow- 
ing the execution of an individual program or a returned 
checkpoint is incorrect, an error signal is sent out from PCI 
300 in Step S2603. However, if all checkpoints are correct 
and received within a timely fashion, the process advances 
to Step S2604 where PCI 300 prepares to send test programs 
to the NEB. 

At Step S2605, the POST program is complete and NEB 
2 waits for instructions from across any one of the ports, 
preferably the serial port. The waiting period can be approxi- 
mately a one second window in which time PCI 300 should 
respond with the prepared text programs. In Step S2606, if 
PCI 300 does not respond by sending a test program to NEB 
2 within the time window, flow advances to Step S2607 
where the NEB enteres its normal operational mode. 

When the test program instruction set from PCI 300 is 
received in Step S2606, the instruction set, which includes 
further test programs, is stored (in Step S2608) on NEB 2 in 
DRAM 220. In Step S2609, PCI 300 activates the instruc- 
tion set and NEB 2 executes each test program within the 
instruction set. 

The test program instruction set may contain, in random 
order, test programs which require NEB 2 to configure PC2 
306 as a LAN peripheral device, or which require NEB 2 to 
configure PC2 306 as an SCSI peripheral device. In either 
case, after being configured, PC2 306 will respond to each 
communication from NEB 2, usually by merely returning 
data blocks sent by the NEB. 

Briefly, in Step S2610 (FIG. 26B) NEB 2 configures PC2 
306 as a LAN peripheral and PC2 306 responds by sending 
a response to NEB 2 which effectively performs a LAN 
loopback test by returning the data which' it has received. 
NEB 2 will communicate with PC2 and receive simulated 
print job results. In Step S2611, the result of each block job 
is sent to PCI 300. PCI 300 determines if the test result is 
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correct. In Step S2611, if it is determined by PCI 300 that 
the test result is incorrect, PCI 300 sends a re-scripted, 
branch test program (Step S2612) in accordance with the test 
result received in Step §2611. However, if no further branch 
test program exists, then in Step S2612 PCI 300 will stop 5 
LAN testing and output an error signal. 

Thus, in Step S2611, NEB 2 is tested for LAN commu- 
nications. Assuming NEB 2 successfully passes each LAN 
communication test, flow advances to Step S2613 at which 
point PC2 306 is configured as an SCSI peripheral device 10 
and performs SCSI loopback tests by returning the data 
which it has received. In Step S2614 the results of the tests 
are sent to PCI 300 and if the results are incorrect, PCI 300 
similarly sends a branch test in Step S2615 in accordance 
with the test result. Of course, if no further branch test exists 15 
to further test the peripheral communication, then PCI 300 
stops the test, and outputs an error signal. 

Assuming that NEB 2 successfully passes each SCSI 
communication test in Step S2614, then flow advances to 
Step S2616 at which point NEB 2 requests further instruc- 20 
tions from PCI 300. If PCI 300 returns with further instruc- 
tions, flow returns to Step S2605, but if further testing is not 
necessary then NEB testing is ended. 

In summary, a method for testing an interactive network 
board having a LAN interface and a test interface comprises 25 
the steps of applying power to the board and reading a POST 
result which was executed out of board ROM via the test 
interface, and downloading a test program into the board 
RAM via the test interface. The test program is then acti- 
vated for execution out of board RAM. The board may then 30 
be commanded to configure a peripheral device (through 
either the LAN or the SCSI interface) to be a LAN driver or 
an SCSI peripheral. The board then interacts with the LAN 
driver or SCSI peripheral in accordance with the test pro- 
gram. Results of the lest program are then output via the test 35 
interface to a test computer which receives these test results. 
If certain tests fail, additional test programs may be scripted 
in accordance with the type of failure. The newly scripted 
test programs will be able to perform fault detection and 
diagnosis, and these additionally scripted test programs may 40 
then be downloaded to the board RAM from the PCI. 

Once all of the tests are successfully concluded, it may be 
convenient (in the factory test environment) to flash the 
operational firmware into EPROM 222. Specifically, the last 
step of a testing program may be utilized to load the requisite 45 
firmware image into the NEB EPROM 222 prior to delivery 
(see section 4q above). The firmware flashed to EPROM 222 
may also include a unique MAC address for NEB 2. 

In the past, MAC addresses were incorporated into circuit 
boards using a dedicated PROM chip such as PROM 232. 50 
However, it has been found that if the MAC address is 
flashed into EPROM, the PROM chip is mot required, while 
the MAC address can still be stored in a non- volatile way. 
(Of course, as discussed in paragraph 4q, the MAC address 
could also be remotely flashed into the EPROM at the same 55 
time the RAM firmware image is updated, after NEB 2 is 
coupled to the LAN.) 

In Step S2617 of FIG. 26B, NEB testing has been 
completed and each board may be designated with its own 
individual identifier number, commonly referred to as a 60 
MAC address. Thus, in Step S2617 it is determined whether 
a ROM firmware image is to be stored in EPROM 222. If no 
image is to be stored, testing ends. However, if an image is 
to be stored, flow advances to Step S2618 where the ROM 
image (with MAC address) is flashed to EPROM 222. At 65 
Step S2618 it may also be desirable to download other data 
normally stored in PROM 232, such as board revision 
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number, data of manufacture, tester name, etc., together with 
the MAC address. 

Two possible scenarios have been considered for flashing 
the ROM firmware and MAC address to EPROM 222. In the 
first case the NEB 2 has been pre-loaded with a sophisticated 
set of diagnostics for use in manufacturing tests. This 
approach limits the amount of time needed to download the 
specific tests since they will be already present in the 
firmware. In this case, after the tests are successful the final 
production version of the firmware is loaded into the board 
and flashed along with the MAC address and other hardware 
related information such as board revision, manufacturing 
data, and tester (Step S2618). In the second case the board 
will be built with the final production version of the firm- 
ware. In this case the board specific information area will be 
left blank and only this area loaded and flashed after a 
successful test execution in Step S2618. 

In summary, a method for post-test loading of program- 
mable firmware into an interactive network board having a 
LAN interface comprises the step of downloading a ROM 
firmware image (including the MAC address) to DRAM 220 
via the LAN interface. The integrity of the ROM image is 
then confirmed, and the board is commanded to electroni- 
cally erase the EPROM. The EPROM is then flashed with 
the ROM image which includes the MAC address, and-the 
board is then re-booted from EPROM. 

Thus, what has been described in detail above is an 
interactive network circuit board including structure and 
function for coupling a peripheral to a LAN so that the 
peripheral is a responsive interactive member of the LAN. 

While the present invention has been described with 
respect to what is considered to be the preferred embodi- 
ments, it is to be understood that the present invention is not 
limited to the disclosed embodiments. To the contrary, the 
present invention is intended to cover various modifications 
and equivalent arrangements included within the spirit and 
scope of the appended claims. The scope of the following 
claims is to be accorded the broadest interpretation so as to 
encompass all such modifications and equivalent structures 
and functions. 

What is claimed is: 

1. In a local area network, a method for remotely updating 
an old ROM firmware image stored in a PROM disposed on 
a designated interactive network board having a local area 
network interface, said method comprising the steps of: 
activating a local area network communication program, 
said communication program operating (i) to broadcast 
an inquiry through the local area network for the 
designated interactive network board, (ii) to receive 
location information of the designated interactive net- 
work board in response to the broadcast inquiry, and 
(iii) to establish communication with the designated 
interactive network board via the local area network 
interface; 

downloading, over the local area network interface, a new 
ROM firmware image into a RAM on the designated 
interactive network board; 

verifying that the new ROM firmware image stored in the 
RAM is valid prior to loading the new ROM firmware 
image from the RAM into the PROM; 

updating firmware of the PROM, in a case where the new 
ROM firmware image is valid, by (i) storing a predes- 
ignated portion of the old ROM firmware image in the 
RAM, (ii) erasing predetermined PROM storage loca- 
tions, and (iii) loading the new ROM firmware image 
and the predesignated portion of the old ROM firmware 
image from the RAM into the PROM; and 
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re-initializing the designated interactive network board, in 
a case where the new ROM firmware image is valid, 
using the new ROM firmware image and the predes- 
igned portion of the old ROM firmware image loaded 
in the PROM. 5 

2. A method according to claim 1, further comprising the 
step of, after said step of re-initializing, loading instructions 
from the PROM to the RAM. 

3. A method according to claim 1, wherein the step of 
activating includes the step of storing the new ROM firm- j 0 
ware image in a local area network file server. 

4. A method according to claim 3, wherein the step of 
downloading includes the step of retrieving, from the local 
area network file server, the new ROM firmware image. 

5. A method according to claim 1, further comprising the 15 
step of matching a designated identifier stored in the PROM 
with a designated identifier in the new ROM firmware image 
stored in the RAM, and in the case the designated identifier 
stored in the PROM does not match the designated identifier 
stored in the RAM, further including the step of outputting 20 
an error signal from said board. 

6. A method according to claim 1, wherein said step of 
verifying performs a checksum operation on the new ROM 
firmware image stored in the RAM and, in the case the 
checksum operation fails, performs a further step of output- 25 
ting an error signal from said board indicating that the 
checksum operation has failed. 

7. A method according to claim 1, wherein said step of 
controlling controls the PROM to erase all memory loca- 
tions except a board identifier location. 30 

8. A method according to claim 7, wherein said step of 
updating loads the new ROM firmware image from the 
RAM into erased memory locations of the PROM. 

9. A method according to claim 1, wherein the activating 
step broadcasts a MAC address through the LAN and 35 
established communication with the board after the board 
has responded to the inquiry by sending its address and 
location. 

10. A method according to claim 1, further comprising the 
step of disposing a test interface on said board for providing 40 
a communication link to a test station, and wherein said step 

of downloading includes the step of downloading the new 
ROM firmware image, the designated identifier, and a 
checksum through the test interface from the test station into 
the RAM. 45 

11. A method according to claim 1, further comprising the 
step of disposing a remote LAN device for remotely down- 
loading the new ROM firmware image, the designated 
identifier, and a checksum packet into the RAM via the local 
area network interface. 50 

12. A method according to claim 1, further comprising the 
step of disposing a SCSI interface on the board. 

13. A method according, to claim 1, further comprising a 
step of verifying a designated identifier in the new ROM 
firmware image with a designated identifier stored in a ROM 55 
disposed on the designated interactive network board before 
said step of updating. 

14. In a local area network, an apparatus for remotely 
altering an old ROM firmware image stored in a PROM 
disposed on a designated interactive network board having 
a local area network interface, said apparatus comprising: 

local area network communicating means (i) for broad- 
casting an inquiry through a local area network for the 
designated interactive network board, (ii) for receiving 
location information of the designated interactive net- 65 
work board in response to the broadcast inquiry, (iii) for 
establishing communication with the designated inter- 
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active network board via the local area network inter- 
face, and (iv) for downloading to the designated inter- 
active network board, over the local area network 
interface, a new ROM firmware image, a designated 
identifier code, and a checksum packet; 

a RAM, resident on the designated interactive network 
board, for storing the new ROM firmware image, 
designated identifier code, and checksum packet; 

a PROM, resident on the designated interactive network 
board, for storing the old ROM firmware image and 
another designated identifier code; 

comparing means, resident on the designated interactive 
network board, for performing a checksum operation 
on the new ROM firmware image stored in said RAM, 
prior to loading the new ROM firmware image into said 
PROM, using the checksum packet stored in said 
RAM; and 

control means for controlling said PROM, in a case where 
the new ROM firmware image is valid, (i) to preserve 
a predesignated portion of the old ROM firmware 
image by storing the predesignated portion of the old 
ROM firmware image in said RAM, (ii) to erase 
predetermined PROM storage locations, (iii) to load the 
new ROM firmware image and the predesignated por- 
tion of the old ROM firmware image from said RAM 
into said PROM, and (iv) to re-initialize the designated 
interactive network board using the new ROM firm- 
ware image and the predesignated portion of the old 
ROM firmware image loaded in said PROM. 

15. An apparatus according to claim 14, wherein said 
comparing means compares the designated identifier code 
stored in the RAM with the another designated identifier 
code stored in said ROM. 

16. An apparatus according to claim 14, wherein the 
designated interactive network board is coupled to a LAN 
printer. 

17. An apparatus according to claim 14, wherein the RAM 
comprises a dynamic RAM. 

18. An apparatus according to claim 14, wherein the 
PROM comprises a flash EPROM. 

19. Apparatus according to claim 14, further comprising 
a test interface, disposed on said designated interactive 
network board and connected to said RAM, for providing a 
communication link to a test station, and wherein the new 
ROM firmware image, designated identifier, and a checksum 
are downloaded through the test interface from said test 
station into the RAM. 

20. An apparatus according to claim 14, further compris- 
ing a remote LAN device, connected to said local area 
network communicating means via the local area network 
interface, for remotely downloading the new ROM firmware 
image, designated identifier, and checksum packet into the 
RAM. 

21. Apparatus according to claim 14, further comprising 
a SCSI interface disposed on said designated interactive 
network board for providing a communications link to a 
peripheral device. 

22. In a local area network (LAN), an apparatus for 
remotely altering old ROM firmware in a PROM disposed 
on an interactive network board coupled to the LAN, said 
apparatus comprising: 

a LAN interface, disposed on the interactive network 
board, for receiving from a remote LAN location, new 
ROM firmware and a verification signal; 

a RAM, disposed on the interactive network board, for 
storing the new ROM firmware, a predesignated por- 



03/02/2004, EAST version: 1.4.1 



5,623 ; 

59 

tion of the old ROM firmware, and the verification 
signal; and 

a processor, disposed on the interactive network board, for 
(i) causing the new ROM firmware and verification 
signal to be stored in said RAM, (ii) verifying that the 5 
new ROM firmware is valid using the verification 
signal prior to loading the new ROM firmware into the 
PROM, (iii) writing the predesignated portion of the 
old ROM firmware the PROM to said RAM in a case 
where the new ROM firmware is valid, (iv) updating 10 
the old ROM firmware in the PROM by loading the 
new ROM firmware and the predesignated portion of 
the old ROM firmware into the PROM from said RAM 
in a case where the new ROM firmware is valid, and (v) 
re-initializing the interactive network board using the 15 
new ROM firmware and the predesignated portion of 
the old ROM firmware stored in the PROM in a case 
where the new ROM firmware is valid. 
23. In a local area network, an apparatus for remotely 
altering an old ROM firmware image stored in a PROM 20 
disposed on a designated interactive network board having 
a local area network interface coupled to the local area 
network, the local area network interface for downloading a 
new ROM firmware image and a checksum packet over the 
local area network, said apparatus comprising; 25 
a RAM, resident on the designated interactive network 
board, for storing the new ROM firmware image and 
the checksum packet; 
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a PROM, resident on the designated interactive network 
board, for storing the old ROM firmware image; 

comparing means, resident on the designated interactive 
network board, for performing a checksum operation 
on the new ROM firmware image stored in said RAM 
using the checksum packet stored in said RAM in order 
to validate the new ROM firmware image, the check- 
sum operation being performed prior to loading the 
new ROM firmware image into said PROM; and 

control means, resident on the designated interactive 
network board, for controlling said PROM to update at 
least a portion of the old ROM firmware image stored 
in said PROM in a case where the new ROM firmware 
image is valid by (i) transferring portions of the old 
ROM firmware image which are to be preserved to said 
RAM, (ii) erasing from said PROM at least those 
portions of the old ROM firmware image which are not 
to be preserved, (iii) loading from said RAM into said 
PROM the new ROM firmware image and the portions 
of the old ROM firmware image transferred to said 
RAM, and (iv) re-initializing the designated interactive 
network board using the new ROM firmware image and 
the portions of the old ROM firmware image trans- 
ferred to said PROM. 

* * * * * 
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AUTOMATIC RECOVERY OF A repaired using code from a source storage device without 

CORRUPTED BOOT IMAGE IN A DATA loading the operating system. 



PROCESSING SYSTEM 



BRIEF DESCRIPTION OF THE DRAWINGS 



CROSS REFERENCE TO RELATED 
APPLICATIONS 



BACKGROUND OF THE INVENTION 



The novel features believed characteristic of the invention 
are set forth in the appended claims. The invention itself, 
The present invention is related to applications entitled however, as well as a preferred mode of use, further objec- 
METHOD AND APPARATUS FOR UPDATING BOOT lives and advantages thereof, will best be understood by 
CODE IN ADATAPROCESSING SYSTEM ONALOCAL reference to the following detailed description of an illus- 
STORAGE DEVICE, Sen No. 09/527,398; METHOD AND 10 Native embodiment when read in conjunction with the 
APPARATUS FOR COPYING A BOOTABLE IMAGE accompanying drawings, wherein: 

FROM A NETWORK TO A LOCAL BOOT DEVICE IN A FIG. 1 is a pictorial representation of a distributed data 
DATA PROCESSING SYSTEM, Ser. No. 09/527,399; all of processing system in which the present invention may be 
which are filed even date hereof, assigned to the same implemented; 

assignee, and incorporated herein by reference. p IG 2 is a block diagram of a server data processing 

system that may be implemented as a server in accordance 
with a preferred embodiment of the present invention; 

1. Technical Field FIG. 3 is a block diagram of a data processing system 
The present invention relates generally to an improved 20 shown in which the present invention may be implemented; 

data processing system and in particular to a method and FIG. 4 is a block diagram of an image in accordance with 

apparatus for copying data in a data processing system. Still a preferred embodiment of the present invention; 
more particularly, the present invention relates to a method FIG 5 is a fl owc h ar t of a process for copying a bootable 
and apparatus for copying a bootable image from a network from a network t0 a local boot device in accordance 

to a local boot device in a data processing system. 25 with a preferred embodiment of the present invention; and 

2. Description of Related Art FIG. 6 is a flowchart of the process for automatically 
On a computer, an operating system is a master control recovering from a corrupted boot image in accordance with 

program that runs the computer. The operating system is the a preferred embodiment of the present invention, 
first program loaded when the computer is turned on. The 

operating system is typically loaded by a boot code, which 30 DETAILED DESCRIPTION OF THE 

may be part of a basic input/output system (BIOS). The main PREFERRED EMBODIMENT 

part of the operating system is called the kernel and resides with reference now to the figures, FIG. 1 depicts a 

in memory at all times. The operating system sets the pictorial representation of a distributed data processing 
standards for application programs that run on the computer. ^ system j n which the present invention may be implemented. 
All programs and applications must talk to the operating Distributed data processing system 100 is a network of 
system. Operating systems perform various functions, such computers in which the present invention may be imple- 
as providing user interface, job management, task mented. Distributed data processing system 100 contains a 
management, data management, device management, and network 102, which is the medium used to provide commu- 
secunty. ^ nications links between various devices and computers 

Often times, the operating system will be updated to connected together within distributed data processing sys- 
implement corrections to bugs and errors and to provide new tern 100. Network 102 may include permanent connections, 
features. Further, updates to operating systems also may be such as wire or fiber optic cables, or temporary connections 
provided to provide support to additional devices. Typically, made through telephone connections, 
if the operating system is booted from a local storage device, 45 \ n the depicted example, a server 104 is connected to 
applications running under the operating system are used to network 102 along with storage unit 106. In addition, clients 
update the image on the local storage device. This method of 108, 110, and 112 also are connected to network 102. These 
updating the image onjhejocal storage ; device occurs with clients J108,„ 110, and .112 rnayjxs,. for„ example,_personal 
the operating system executing on the data processing computers or network computers. For purposes of this 
system. This operating system is the one booted from the 5Q application, a network computer is any computer, coupled to 
local storage device. If the image for the operating system is a network, which receives a program or other application 
corrupted, and the operating system cannot be booted from f rom another computer coupled to the network. In the 
the local storage device, this method using the operating depicted example, server 104 provides data, such as boot 
system cannot be employed. files, operating system images, and applications to clients 

Therefore, it would be advantageous to have an improved 55 108-112. Clients 108, 110, and 112 are clients to server 104. 
method and apparatus for updating operating system images Distributed data processing system 100 may include addi- 
and recovering from corrupted operating system images on tional servers, clients, and other devices not shown. FIG. 1 
a data processing system. is intended as an example, and not as an architectural 

limitation for the present invention. 
60 Distributed data processing system 100 may be, for 
The present invention provides a method and apparatus in example, the Internet with network 102 representing a 
a data processing system for automatically restoring an worldwide collection of networks and gateways that use the 
operating system on a local storage device. Prior to loading TCP/IP suite of protocols to communicate with one another, 
the operating system, a determination is made as to whether At the heart of the Internet is a backbone of high-speed data 
the operating system on the local storage device is corrupted 65 communication lines between major nodes or host 
in response to starting the data processing system. If the computers, consisting of thousands of commercial, 
operating system is corrupted, the operating system is government, educational and other computer systems that 
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route data and messages. Of course, distributed data pro- also may be used in addition to or in place of the hardware 

cessing system 100 also may be implemented as a number depicted. The depicted example is not meant to imply 

of different types of networks, such as for example, an architectural limitations with respect to the present inven- 

intranet, a local area network (LAN), or a wide area network lion. 

(WAN). In such a case, a client, such as client 108, may 5 The data processing system depicted in FIG. 2 may be, for 

examine the operating system when client 108 is started. If example, an IBM RISC/System 6000 system, a product of 

the operating system is corrupt or contains errors, the boot International Business Machines Corporation in Armonk, 

code in client 108 may request another copy of the operating NY > running the Advanced Interactive Executive (AIX) 

system or portions of the operating system to replace or operating system. 

correct the corrupted operating system in client 108. 10 Wilh reference now to FIG. 3, a block diagram of a data 

„ . . -i aa lt processing system is shown in which the present invention 

Further, debuted data processing system 100 may take * be f ' lemented Data processing system 300 is an 

l i!fo f °« ° f 3 manufacturm g faciht y lD f whK \ h * ht ** example of a client, such as client 108, 110, or U2 in FIG. 
108-112 are new computers being manufactured. In this x m whkh code Qr inslructioDS implementing the processes 
configuration, network 102 takes the form of a local area of the present invention may be located. Data processing 
network. Clients 108-112 have local storage devices ^ sy$tem 300 employs a peripheral component interconnect 
installed within them. These local storage devices do not (PCI) local bus architecture. Although the depicted example 
contain an operating system. A BIOS or other boot code also employs a PCI bus, other bus architectures such as Accel- 
is installed within clients 108-112. When clients 108-112 erated Graphics Port (AGP) and Industry Standard Archi- 
are started, the boot code looks for an operating system in tecture (ISA) may be used. Processor 302 and main memory 
the local storage device. When an operating system cannot 20 304 are connected to PCI local bus 306 through PCI bridge 
be found, the boot code in these computers look to server 308. PCI bridge 308 also may include an integrated memory 
104 to obtain a copy of the operating system. The boot code controller and cache memory for processor 302. Non- 
includes a mechanism to establish a communications link to volatile memory 309 also is connected to PCI local bus 306 
server 104 across network 102. The operating system is and, in this example, contains a BIOS, which includes a boot 
copied onto the local storage devices on clients 108-112. In 25 code. In this example, non-volatile memory 309 may take 
this manner, a mechanism for creating an initial bootable the form of a non-yolatile random access memory or an 
image on a local storage device is provided without having erasable programmable read only memory (EPROM) In the 
to have the operating system placed on the local storage de P lcted samples, the operating system also may be located 
device prior to installation of the local storage device. ™ non-volatile memory 309. 

™ r t-y^<i iiij* c j 30 Additional connections to PCI local bus 306 may be made 

Referring to FIG. 2, a block diagram of a server data , ,. . . . J . , , . 

& . , • t j t through direct component interconnection or through add-in 

processmg system that may be .mplemented as a server, such ^ , n ^ ^ ^ netwofk (LAN) 

as server 104 in FIG. 1, is depicted m accordance with a j , « . . ■ * c c^cm u . u 

i i j adapter 310, small computer system interface SCSI host bus 

preferred embodiment of the present invention. Server data , r . , ' , . . . t - t . 

r , r i t.- . adapter 312, and expansion bus interface 314 are connected 

processing system 200, m these examples is a location at tQ ^ ^ bus ^ direct Mnl conneclion . In 

which a bootable image may be located. As illustrated ^ audio f ^ ics f m ^ 

below, this bootable image is in the form of an operating connected tQ pa ^ bug 3M by add _ in boards inserted 

system for a client computer. ^ expansion slots Expansion bus interface 314 providcs 

Sever data processmg system 200 may be a symmetric a connection for a keyboard and mouse adapter 320, modem 

multiprocessor (SMP) system including a plurality of pro- 4Q 322 and local storage device 324 storage device 324 

cessors 202 and 204 connected to system bus 206. m this example, contains an image of the operating system. 

Alternatively, a single processor system may be employed. ^ boQ{ code in non . vo i al n e me mory 309 will boot the 

Also connected to system bus 206 is memory controller/ operatiDg system image located in local storage device 324. 

cache 208, which provides an interface to local memory 209. st0fage device 324 may take various formS) such as a 

I/O bus bridge 210 is connected to system bus 206 and 45 fiash mcm0fy . FIash memory is a memory chip than caQ be 

provides an interface to I/O bus 212. Memory controller/ rewritten and hold its content without ^ Flash memory 

cache 208 and I/O bus bridge 210 may be integrated as ^ a type of non _ volatile mem ory. Flash memory may take 

depicted. various forms, such as a memory- stick, which is a flash 

Peripheral component interconnect (PCI) bus bridge 214 memory card designed for various devices. These memories 

connected to I/O bus 212 provides an interface to PCI local 50 typically vary from 4 MB to 192 MB, but may come in 

bus 216. A number of modems may be connected to PCI bus larger sizes. Of course, local storage device 324 may take 

216. Typical PCI bus implementations will support four PCI other forms, such as, for example, a floppy disk drive, a 

expansion slots or add-in connectors. Communications links CD-ROM, or a read-only memory. SCSI host bus adapter 

to network computers 108-112 in FIG. 1 may be provided 3 j^ provides a connection for hard disk drive 326, tape drive 

through modem 218 and network adapter 220 connected to 55 32 8, and CD-ROM drive 330. Typical PCI local bus imple- 

PCI local bus 216 through add-in boards. mentations will support three or four PCI expansion slots or 

Additional PCI bus bridges 222 and 224 provide inter- add-in connectors, 

faces for additional PCI buses 226 and 228, from which An operating system runs on processor 302 and is used to 

additional modems or network adapters may be supported. coordinate and provide control of various components 

In this manner, data processing system 200 allows connec- 60 within data processing system 300 in FIG. 3. The operating 

tions to multiple network computers. A memory-mapped system may be a commercially available operating system 

graphics adapter 230 and hard disk 232 may also be con- such as Windows 2000, which is available from Microsoft 

nected to I/O bus 212 as depicted, either direcdy or indi- Corporation. Instructions for the operating system and appli- 

rectly. cations or programs are located on storage devices, such as 

Those of ordinary skill in the art will appreciate that the 65 hard disk drive 326 and local storage device 324, and may 

hardware depicted in FIG. 2 may vary. For example, other be loaded into main memory 304 for execution by processor 

peripheral devices, such as optical disk drives and the like, 302. 
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Those of ordinary skill in the art will appreciate that the present invention. Image 400 includes a header 402 and an 

hardware in FIG. 3 may vary depending on the implemen- operating system 404. Image 400, in this example, is a 

tation. Other internal hardware or peripheral devices, such as bootable image. The header 402 is used to process the file 

flash ROM (or equivalent non-volatile memory) or optical while operating system 404 is the file that is to be stored in 

disk drives and the like, may be used in addition to or in 5 the local storage device. In this example, header 402 

place of the hardware depicted in FIG. 3. Also, the processes includes an ID field 406, a type field 408, and an error 

of the present invention may be applied to a multiprocessor checking (EC) field 410. 

data processing system. ID field 406 is used to identify whether the image is for 

For example, data processing system 300, if optionally the local storage device. Further, this field also may be used 

configured as a network computer, may not include SCSI JO to identify the type of image. For example, the image for the 

host bus adapter 312, hard disk drive 326, tape drive 328, local storage device is an operating system. In these 

and CD-ROM 330, as noted by dotted line 332 in FIG. 3 examples, ID field 406 is a sequence of 4-5 bytes, but may 

denoting optional inclusion. In that case, the computer, to be take any form depending on the implementation, 

properly called a client computer, must include some type of Next, type field 408 is used to identify a type of platform, 

network communication interface, such as LAN adapter 15 Hardware platforms may vary depending on the application. 

310, modem 322, or the like. As another example, data The information in this field is used to determine whether the 

processing system 300 may be a stand-alone system con- platform on which this image is being loaded is the correct 

figured to be bootable without relying on some type of platform. Next, EC field 410 contains a checksum, which is 

network communication interface, whether or not data pro- a calculated value used to test data for the presence of errors 

cessing system 300 comprises some type of network com- 20 tnat can occur wnen ^a is transmitted or when it is written 

munication interface. As a further example, data processing to a disk. The checksum is calculated for a chunk of data by 

system 300 may be a personal digital assistant (PDA) sequentially combining all of the bytes of data with a series 

device, which is configured with ROM and/or flash memory of arithmetic or logical operations. After the data is trans- 

in order to provide non-volatile memory for storing operat- mined or stored, the new checksum is calculated in the same 

ing system files and/or user-generated data. 25 way usmg the transmitted or stored data. If the two check- 

The depicted example in FIG. 3 and above-described sums do not match, then an error has occurred, and the data 

examples are not meant to imply architectural limitations. should be transmitted or stored again. Of course, other 

For example, data processing system 300 also may be a mechanisms may be used to determine whether errors are 

notebook computer, hand held computer, or palmtop in present in the image. 

addition to taking the form of a PDA. Data processing 30 For example, cyclical redundancy checking (CRC) infor- 

system 300 also may be a kiosk or a Web appliance. mation may be placed in EC field 410. CRC involves using 

The present invention provides a method, apparatus, and a calculation to generate a number based on the data 
computer implemented instructions for enabling boot code transmitted. The sending device performs the calculation 
to copy an image from a network to a local storage device. before transmission and sends the result to a receiving 
In the depicted examples, this image is the operating system 35 device. The receiving device repeats the same calculation 
that is to be booted. The mechanism of the present invention after transmission. If the result is the same then the trans- 
may be implemented in instructions, such as those found in mission is assumed to be error free, 
boot code, which are used to initialize hardware in data Image 400, in these examples, includes an operating 
processing system 300 and to load the operating system in system 404. of course, other types of images, such as, for 
data processing system 300. example, an image of boot code may be transferred using 

The mechanism of the present invention may be this mechanism, 
employed in manufacturing to create an initial bootable With reference now to FIG. 5, a flowchart of a process for 
image on the local storage device. For example, a blank copying a bootable image from a network to a local boot 
storage device, such as a compact flash card, may be 45 device is depicted in accordance with a preferred embodi- 
installed during early manufacturing steps. When initially m ent of the present invention. This process may be imple- 
powered, the boot code copies the operating system to the mented in boot code in these examples, 
compact . flash memory ^card. In the depicted example, a boot ^ process begins by initializing the-hardware (step 
code menu is used to provide a mechanism to point to a file 500 ) Nextj a netW ork connection is established to the 
on a server or elsewhere on a network. A user may input a 5Q network ( step 5 Q2). Thereafter, a specified file is down- 
path or universal resource identifier to identify a location of loaded from the network (step 504). The file may be 
a file or image. The location of this file or image may be identified using a resource identifier, which may be, for 
stored within a non-volatile storage device. This may be the example, a path name or a universal resource locator. The 
same device on which the boot code is located. location of the file may be specified using a number of 

This mechanism eliminates the need to preprogram a flash 55 different mechanisms. For example, boot code menus may 

memory card prior to installing the flash memory card on a provide a mechanism for specifying the location of the file 

data processing system. in which this location is stored in a NVRAM. If the location 

Further, the present invention also provides a mechanism is stored in a NVRAM, this location aiso may be specified 

to recover from corruption of an operating system on the through the use of an application running on the operating 

local storage device. When the system boots, a check is 60 system. 

made to see whether the operating system is a good oper- Alternatively, the location of the file may be specified 
ating system or whether the operating system is corrupted. using standard network operations, such as, for example, 
If the operating system is corrupted or contains errors, a file dynamic host configuration protocol (DHCP) and boot strap 
or image is read from a network and is used to rebuild or protocol (BOOTP). These protocols are used to allow net- 
replace the operating system on the local storage device. 65 work computers to obtain IP addresses and to access other 
TUrning next to FIG. 4, a block diagram of an image is information. Location information for a file may be provided 
depicted in accordance with a preferred embodiment of the through these protocols. 
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After the file is downloaded, a header in the file is parsed It is important to note that while the present invention has 

(step 506). A determination is then made as to whether this been described in the context of a fully functioning data 

is an image for the local storage device (step 508). processing system, those of ordinary skill in the art will 

If the image is for the local storage device, a determina- appreciate that the processes of the present invention are 

tion is then made as to whether the image is a good image 5 capable of being distributed in the form of a computer 

(step 510). Step 510 is used to see whether the image is readable medium of instructions and a variety of forms and 

corrupted. The determination as to whether the image is for that the present invention applies equally regardless of the 

a local storage device, such as a flash memory, may be made particular type of signal bearing media actually used to carry 

in a number of different ways. For example, a header may be out the distribution. Examples of computer readable media 

placed at the beginning of the file in which error checking 10 include recordable-type media, such as a floppy disk, a hard 

information, such as a checksum or CRC, is located. This disk drive, a RAM, CD-ROMs, DVD-ROMs, and 

information is used to determine whether errors have transmission -type media, such as digital and analog com- 

occurred in transmission of the image from the network to munications links, wired or wireless communications links 

the data processing system. If the image is a good image, the using transmission forms, such as, for example, radio fre- 

local storage device is updated with the image (step 512) que acy and light wave transmissions. The computer read- 

with the process terminating thereafter. able media may take the form of coded f ormals that are 

With reference again to step 510, if the image is not a decoded for actual use in a particular data processing 

good image, then an error message is generated (step 514) system. 

with the process terminating thereafter. With reference again description of the present invention has been pre- 

to step 508, if the image is not an image for the local storage ^ for pur p 0se s of illustration and description, and is not 

device then the file is executed (step 516) with the process intended to be exhaustive or limited to the invention in the 

terminating thereafter. form disclosed. Many modifications and variations will be 

With reference now to FIG. 6, a flowchart of the process apparent to those of ordinary skill in the art. The embodi- 

for automatically recovering from a corrupted boot image is meQt was chosen and described in order to best explain the 

depicted in accordance with a preferred embodiment of the 25 principles of the invention, the practical application, and to 

present invention. enable others of ordinary skill in the art to understand the 

The process begins by initializing the hardware (step invention for various embodiments with various modifica- 

600). Thereafter, the image is loaded from the local storage tions as are suited to the particular use contemplated, 

device (step 602) then the file is checked (step 604). The What is claimed is: 

check may be implemented using various mechanisms for 30 1. A method for automatically restoring an operating 

error checking. The information used for error checking may system on a local storage device in a data processing system, 

be located in a header, such as header 402 in FIG. 4. For comprising the steps of; 

example, a checksum, a cyclical redundancy check (CRC), determining whether the operating system on the local 

or some other similar method may be used for checking for storage device is corrupted in response to starting the 

errors. 35 data processing system; and 

A determination is made as to whether the file is corrupted repairing the operating system using code from a source 

based on the check (step 606). If the file is corrupted, then storage device without loading the operating system if 

a determination is made as to whether a recovery file is the operating system is corrupted, 

specified (step 608). The specification of this file may be 2. The method of claim 1, wherein the step of repairing the 

located in a memory on the system, such as a non-volatile 40 operating system comprises: 

random access memory (NVRAM) in which the boot code replacing the operating system on the local storage 

is located. Of course, other non-volatile storage may be used device. 

to indicate such a file. If a recovery file is specified, then the 3 method 0 f claim 1, wherein the repairing step 

recovery file is loaded and an update is made to the local comprises: 

storage device to correct for the corruption (step 610) with 45 . ' a kefnel fof the operatirjg system from lhe 

the process then returning to step 600 to reboot the system. stQ device tQ the ^ st0fage device; 

The location of the file may be identified m a fashion similar , , , . 

t .... ™^ . „ 7 . J t • j * 1 * . u loading the kernel; and 

to that in FIG. 5. When a corrupt or bad kernal is toJ>e . 0 t 

replaced on the local storage "device; the location of the file " ' pa^g contrd to the kernel - - - 

for the kemal is typically read from the NVRAM. 50 4 ™ e method of claim 3, wherem the kernel performs 

.... , c • \ sno c £i • any additional repairs to place the operating system in an 

With reference again to step 608, if a recovery file is uncorru ted condition 

unspecified, then an error is generated (step 614) with the _ „, p . e * \ . - A 

y * . . , - r • * t 5. The method of claim 3 further comprising: 

process terminating thereafter. With reference back to step , , . t . , ,. . 

606, if the check indicates that file corruption is absent, then res ' artm f *» da,a P"*""* s y stem P"° r t0 loadin 8 lhe 

the operating system is booted (step 612) with the process 55 , ^ De * , , r , . . , 

terminating thereafter. 6 * ™e method of claim X ' wherein the re P ainn S ste P 

Thus, the present invention provides an improved comprises, 

method, apparatus, and computer implemented instructions establishing a network connection to a server; 

for copying images or recovering from corrupted images on copying a kernel for the operating system from the source 

the local storage device. In particular, the mechanism may 60 stora 8 e device 0D lne server t0 the local slora g e device i 

be used to create, update, or replace images, such as, for loading the kernel; and 

example, operating system images, on a local storage passing control to the kernel, 

device. The mechanism of the present invention also pro- 7. The method of claim 6 further comprising 

vides a mechanism for recovering from a corrupted operat- copying other portions of the operating system from the 

ing system. This mechanism avoids having to replace a local 65 source storage device to the local storage device, 

storage memory or boot the operating system from a server 8. The method of claim 1, wherein the determining and 

and run an application to rebuild the operating system. repairing steps are performed by a boot code. 
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9. The method of claim 8, wherein the boot code is located 
in a non volatile memory in the data processing system. 

10. The method of claim 1, wherein the local storage 
device is one of a nonvolatile random access memory, a hard 
disk drive, a floppy disk drive, a CD-ROM, and a DVD- 5 
ROM. 

U. The method of claim 1, wherein error checking 
information is present on the data processing system and 
wherein the determining step is performed using the error 
checking information. 10 

12. A data processing system comprising: 
a bus; 

a non volatile memory connected to the bus, wherein a 

boot code is located in the nonvolatile memory; 
a local storage device connected to the bus; and 
a processor connected to the bus, wherein the processor 
executes the boot code to determine whether an oper- 
ating system is present in the local storage device, and 
copies the operating system from a remote location to 2 o 
the local storage device through a data link from the 
data processing system to the remote location if the 
operating system is absent from the local storage 
device. 

13. The data processing system of claim 12, wherein the 2 s 
non volatile memory is a non volatile random access 
memory. 

14. The data processing system of claim 12, wherein the 
local storage device is a non volatile random access memory, 
hard disk drive, floppy disk, CD-ROM, and DVD-ROM. 30 

15. The data processing system of claim 12, wherein the 
data processing system is a laptop computer, palmtop 
computer, personal computer, and personal digital assistant. 

16. A data processing system for automatically restoring 

an operating system on a local storage device the data 35 
processing system comprising; 

determining means for determining whether the operating 
system on the local storage device is corrupted in 
response to starting the data processing system; and 
repairing means for repairing the operating system using 40 
code from a source storage device without loading the 
operating system if the operating system is corrupted. 

17. The data processing system of claim 16, wherein the 
repairing means comprises: 

replacing means for replacing the operating system on the 45 
local storage device. 

18. The data processing system of claim 16, wherein the 
repairing means comprises: - ... 

copying means for copying a kernel for the operating 5Q 
system from the source storage device to the local 
storage device; 
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loading means for loading the kernel; and 
passing means for passing control to the kernel. 

19. The data processing system of claim 18, wherein the 
kernel performs any additional repairs to place the operating 
system in an uncorrupted condition. 

20. The data processing system of claim 18 further 
comprising: 

restarting means for restarting the data processing system 
prior to loading the kernel. 

21. The data processing system of claim 16, wherein the 
repairing means comprises: 

establishing means for establishing a network connection 
to a server; 

copying means for copying a kernel for the operating 
system from the source storage device on the server to 
the local storage device; 
loading means for loading the kernel; and 
passing means for passing control to the kernel. 

22. The data processing system of claim 21 further 
comprising: 

copying means for copy other portions of the operating 
system from the source storage device to the local 
storage device. 

23. The data processing system of claim 16, wherein the 
determining means and repairing means are performed by a 
boot code. 

24. The data processing system of claim 23, wherein the 
boot code is located in a non volatile memory in the data 
processing system. 

25. The data processing system of claim 16, wherein the 
local storage device is one of a nonvolatile random access 
memory, a hard disk drive, a floppy disk drive, a CD-ROM, 
and a DVD-ROM. 

26. The data processing system of claim 16, wherein error 
checking information is present on the data processing 
system and wherein the determining means is performed 
using the error checking information. 

27. A computer program product in a computer readable 
medium for automatically restoring an operating system on 
a local storage device, the computer program product com- 
prising: 

first instructions for determining whether the operating 
system on the local storage device is corrupted in 
response to starting the data processing system; and 

second instructions for repairing the operating system 
using code from a source storage device without load- 
ing "the operating* system" if the operating system~is 
corrupted. 

* * * * * 
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(57) ABSTRACT 

Methods, systems and computer program products are pro- 
vided which update firmware in a network computer by 
replacing the standard operating system to be loaded at the 
initialization of the network computer with a firmware 
update operating system. The firmware update operating 
system is then downloaded to the network computer and 
initiated to update the firmware of the network computer. 
The firmware update operating system may then be replaced 
with the standard operating system to be loaded at the 
initialization of the network computer. The network com- 
puter may then be reinitialized by, for example, a cold boot, 
so as to load the standard operating system. The cold boot 
may be server initiated so as to allow for firmware updates 
with intervention by an operator at the network computer. 
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METHODS, SYSTEMS AND COMPUTER 
PROGRAM PRODUCTS FOR SECURE 
FIRMWARE UPDATES 

FIELD OF THE INVENTION 5 

This invention relates to computer systems, methods and 
program products, and more particularly to personal com- 
puter and network computer systems, methods and program 
products. 

10 

BACKGROUND OF THE INVENTION 

Personal computers are widely used in consumer and 
commercial environments. Personal computers include, but 
are not limited to, IBM® and IBM-compatible computers 
which operate in a Windows® or OS/2® environment. 
Personal computers can also include workstations operating 
in a Unix® or other environment. As is well known to those 
having skill in the art, a personal computer includes a central 
processing unit (also referred to as a "system unit") and a 
user interface that is responsive to user input and to the 
central processing unit. The user interface generally includes 
a display, a keyboard, and a pointing device such as a mouse. 
The personal computer also includes persistent storage such 
as a hard disk drive that stores programs and data. An 
operating system such as Windows 95®, OS/2® or Unix® 25 
is also stored in the persistent storage. A plurality of appli- 
cations programs such as computer games or an office suite 
are also generally stored in the persistent storage. 

Personal computers also may include a network interface 3Q 
application that communicates with a server over a network. 
The network interface application may be an Internet inter- 
face that communicates with the Internet using HTTP or 
other protocols. Examples of network interface applications 
include Netscape® Navigator® and Microsoft® Internet 35 
Explorer®. 

As personal computers and their application programs 
become more sophisticated, it is becoming increasingly 
clear that their total cost of ownership, including hardware 
and software maintenance and upgrades, may be much 40 
larger than the initial cost of the hardware and software 
itself. In fact, up to $35,000 or more may be spent annually 
to maintain each personal computer in a corporate environ- 
ment. 

Network computers have been proposed in order to 45 
reduce this overall cost of ownership. Network computers 
generally do not require a user or administrator to install 
software on the computer. Rather, all software is loaded 
from a network server when the network computer is started 
or when needed during a session. The overall specifications 50 
for network computers are described in a document entitled 
Profile Definition: Network Computer, XlOpen, Document 
Number: X975, published by The Open Group, Berkshire, 
UK (1997), the disclosure of which is hereby incorporated 
herein by reference. Network computers have presently been 55 
announced and/or shipped by IBM Corp. (Network Station, 
Series 100, 300 and 1000), Sun Microsystems (Java 
Station), Oracle (N.C.), Neoware (Neostation), Wyse 
(Winterm), Acorn (Netstation) and Corel Computer Corp. 
(Corel Video Network Computer). eo 

Programs for network computers are typically written in 
Java. As is well known to those having skill in the art, Java 
programs, in compiled form, are generally portable and will 
generally run on a wide range of computers and operating 
systems. Java programs support referencing Universal 65 
Resource Locator (URL) identifiers with content types of 
audio/basic, audio/x-wav, image/gif and image/jpeg. Java 



,809 Bl 

2 

provides a machine dependent desktop for executing 
machine independent applets. 

Network computers are also known as "diskless comput- 
ers" because they generally do not include persistent storage 
such as a floppy disk, hard disk or CD-ROM. Due to the lack 
of a disk, all programs and data, except for a small loading 
program, are obtained from the server. 

FIG. 1 is a simplified block diagram of a network com- 
puter that is connected to a server using an Internet connec- 
tion. As shown in FIG. 1, network computer 100 includes a 
central processing unit 102 (also referred to as a "system 
unit") and a user interface including a display 104, a 
keyboard 106, and a pointing device (mouse) 108. As also 
shown in FIG. 1, the network computer does not generally 
include persistent storage for storing programs and data. A 
limited amount of volatile storage such as Random Access 
Memory (RAM) may be used to temporarily store applica- 
tions and data while the network computer is running, but 
this volatile storage loses its information when the network 
computer is turned off. The network computer may also 
include permanent storage such as Read Only Memory, 
which may store a URL identifier to identify the server with 
which the computer works. The permanent storage may also 
include a base key which is used for security purposes. 

Network computer 100 also includes a network interface 
110 that allows the computer to communicate with a server 
120 using a network such as the Internet 130. As shown in 
FIG, 1, server 120 generally includes Hypertext Transfer 
Protocol (HTTP), Bootstrap Protocol (BOOTP), Dynamic 
Host Configuration Protocol (DHCP), Network File System 
(NFS) and Trivial File Transfer Protocol (TFTP) servers. 
The server 120 also stores operating system images and a 
Java Runtime Environment (JRE). A Java desktop and other 
applications may also be included. Other non-Java related 
applications may also be included. 

During initialization, the network computer typically car- 
ries out a process similar to that of a personal computer. The 
network computer begins by performing a power on self test 
(POST) followed by execution of program code which loads 
the operating system from the network server. The operating 
system is then initialized and any further processing is 
performed utilizing the operating system (e.g. loading of the 
JRE). The program code which resides on the network 
computer is often referred to as "firmware" because it is 
persistently stored in the computer hardware. 

In order to load the operating system, the program code 
which resides on the network computer should be able to 
initialize the network interface and other peripherals asso- 
ciated with the network computer. Thus, the firmware may 
have device dependent program code and may be required to 
change over time. Furthermore, as peripherals are added to 
the network computer there may be a need to revise the 
firmware to account for these peripherals. Additionally, the 
initialization code or the POST procedure may also need to 
change from that originally provided with the network 
computer. 

Traditionally, firmware and device drivers which reside 
on a personal computer are updated by installing new 
firmware or device drivers from a portable storage media 
such as a floppy disk drive, CDROM, or hard disk. 
Alternatively, the update would be downloaded from a 
commonly accessible storage location such as a bulletin 
board or Internet web site to a persistent local storage 
device. This process, essentially replicates the typical pro- 
cess of updating the firmware from a portable storage media 
by providing the firmware update on persistent storage. In 
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either case, the firmware installation requires a persistent Similarly, the standard operating system may be validated 

local storage media because the update would be accom- before being utilized to initialize the operating system, 

plished by initializing the personal computer (i.e. "booting") By providing for validation of the operating systems at the 

from the persistent local storage media. This operation is network computer, the security of the firmware update may 

typically a manual operation which may require user inter- 5 be further increased. The boot image of the firmware update 

vention at each personal computer to be updated. ma y be confirmed by the network computer so that viruses 

By providing for centralized application management at or other data corruption may be avoided at the network 

the server, network computers may reduce the management computer. 

requirements for a computer network. Furthermore, because i 0 another embodiment of the present invention, whether 

the applications of a network computer are centrally 10 tfae network compu ter firmware is to be updated is deter- 

managed, a user may move from location to location within mined and the update of the firmware conditioned upon this 

the network and still have available the same applications. determination. The determination of the need to update the 

However, because a network computer has no removable or firmware of a network computer may be carried out by a 

local mass storage such as hard disk, CDROM or floppy disk Simple Network Management Protocol (SNMP) query to an 

drives, updating firmware or device drivers which reside on 35 SNMP agent res ident on the network computer. The ability 

the network computer may be difficult, labor intensive and t0 <j etect me need for an update by a server allows for the 

in some situations impossible. Furthermore, there is no local automation of the firmware update process and furthers the 

storage device to download the update to or to boot from to centralization of the update process, 

install the new firmware. Additionally, the download opera- ^ ^ firmwafe u ^ ate ^ ffl ^ alsQ 

tion may be non-secure and may mtroduce the possibility 20 ^ Qf a io ^ 

that a virus or other corrupted data may ^be introduced to the co ten B performing a ^Id rcb oot of the network 

computer. Accordingly, a need exists for improvements in c uter> which be initiatedj an initialization of 

updating firmware for network computers. deyices mchcd tQ ^ netw0fk such as periph eral 

SUMMARY OF THE INVENTION 2 5 ac * a P* er car( ^ s » are a^o reinitialized. Thus, the present inven- 

. , . tion provides for, not only the update of firmware of a 

It is one object of the present invention to provide for network uter> but for lhe update of firmware of devices 

updating the firmware of a network computer without the accessible t0 the network computer, 

need for a floppy drive or other portable storage media. .„ . . . *,.„.. iL 

. . _ , . . . , f As will be appreciated by those of skill in the art, the 

Another object of the present invention is to provide for ( invention F be embodied as systems, methods 

more secure updates of a network computer s firmware. and/Qr computer program products . 

Still another object of the present invention is to provide 

for updating a network computer's firmware without inter- BRIEF DESCRIPTION OF THE DRAWINGS 

vention by the user of the network computer. . . . . . . _ . . 

, . , FIG. 1 is a simplified block diagram of a conventional 

Yet another object of the present invention is to provide 35 netWQrk ^ mat communicates with a ^ over a 

for centralized management of the firmware of network network 1 

computers. ...... * ■ *• FIG. 2 is a block diagram of a network computer accord - 

These and other obiects of the present mvention are . , 

.... * . , r , ing to the present invention; 

provided by methods, systems and computer program prod- © r 

ucts which update firmware in a network computer by 40 FIG - 3 is a flowchart illustration of operations of a 
replacing, at the server, the standard operating system to be network computer embodying the present invention; and 
loaded at the initialization of the network computer with a FIGS. 4a and 4b are a flowchart illustration of operations 
firmware update operating system. The firmware update of network computer systems, methods and computer pro- 
operating system is then downloaded to the network com- gram products according to the present invention, 
puter and initiated to update the firmware of the network 45 
computer. The firmware update operating system may then 
be replaced at the server with the standard operating system 
to be loaded at the initialization of the network computer. The present invention now will be described more fully 
The network computer may then be reinitialized, by for hereinafter with reference to the accompanying drawings, in 
example, a cold boot, so as to load the standard operating 50 which preferred embodiments of the invention are shown, 
system. This invention may, however, be embodied in many different 

By downloading to the network computer an operating forms and should not be construed as limited to the embodi- 
system which updates the network computer's firmware, the ments set forth herein; rather, these embodiments are pro- 
firmware may be updated without the need for portable vided so that this disclosure will be thorough and complete, 
storage media. Furthermore, because the update operating 55 and will fully convey the scope of the invention to those 
system may be downloaded from a common network server, skilled in the art. Like numbers refer to like elements 
the firmware of multiple network computers may be cen- throughout. As will be appreciated by one of skill in the art, 
trally managed. Also, because the update operating system is the present invention may be embodied as methods or 
downloaded from a single source the security which may be devices. Accordingly, the present invention may take the 
utilized with the update operating system may be enhanced. 60 form of an entirely hardware embodiment, an entirely soft- 

In further embodiment of the present invention, the ware embodiment or an embodiment combining software 

update operating system is a boot image of the firmware and hardware aspects. 

update which is downloaded to the network computer. The present invention is described herein with respect to 

Furthermore, the standard operating system may also be a flowchart illustrations of embodiments or aspects of the 

boot image of the standard operating system. Also, after 65 present invention. It will be understood that each block of 

downloading, the firmware update operating system may be the flowchart illustrations, and combinations of blocks in the 

validated prior to the initiating the firmware update. flowchart illustrations, can be implemented by computer 
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program instructions. These program instructions may be 
provided to a processor to produce a machine, such that the 
instructions which execute on the processor create means for 
implementing the functions specified in the flowchart block 
or blocks. The computer program instructions may be 5 
executed by a processor to cause a series of operational steps 
to be performed by the processor to produce a computer 
implemented process such that the instructions which 
execute on the processor provide steps for implementing the 
functions specified in the flowchart block or blocks. 

Accordingly, blocks of the flowchart illustrations support 
combinations of means for performing the specified 
functions, combinations of steps for performing the speci- 
fied functions and program instruction means for performing 
the specified functions. It will also be understood that each 
block of the flowchart illustrations, and combinations of 35 
blocks in the flowchart illustrations, can be implemented by 
special purpose hardware-based systems which perform the 
specified functions or steps, or combinations of special 
purpose hardware and computer instructions. 

FIG. 2 illustrates one embodiment of a network computer 20 
according to the present invention. FIG. 2 illustrates the 
network computer system unit 200 and display 215 as well 
as a smart card 220. As seen in FIG. 2, a network computer 
system unit 200 may include a central processing unit (CPU) 
210, memory 212 which includes flash ROM 218, a network 25 
interface 214 a smart card port 216, a video interface 213. 
The central processing unit 210 may be a microprocessor 
such as an Intel® Pentium® or other microprocessors. The 
memory may include random access memory (RAM), read 
only memory (ROM), electronically erasable programmable 30 
read only memory (EEPROM) or other types of memory 
known to those of skill in the art. Furthermore, the memory 
212 may include cache such as an L2 cache, an instruction 
cache, a data cache or any combination thereof. However, 
according to the present invention, the memory 212 includes 35 
some form of persistent storage such as the flash ROM 218 
for storing the firmware of the network computer. 

The network computer may communicate through the 
network interface 214 with a network server 230. The 
network interface may be any number of network interfaces 40 
known to those of skill in the art, such as token ring or 
ethernet. Furthermore, the network communication protocol 
may be any communication protocol suitable for use with a 
network computer, such as, for example, TCP/IP. 

As will be appreciated by those of skill in the art, 45 
additional features may be incorporated into the network 
computer 200, such as serial and/or parallel communication 
interfaces, video acceleration card, sound and other multi- 
media cards as well as multiple network interfaces. 
Furthermore, a network computer according to the present 50 
invention may include a personal computer emulating a 
network computer such as is disclosed in commonly 
assigned United States Patent Application entitled Network 
Computer Emulator Systems, Methods and Computer Pro- 
gram Products for Personal Computers, the disclosure of 55 
which is incorporated by reference as if set forth fully. 

FIG. 2 also illustrates an access card 220 associated with 
the network computer of the present invention. The access 
card 220 may be a smart card in that a central processing unit 
222 and memory 224 are provided on the access card 220. 60 
When the access card 220 is placed in the smart card port of 
the network computer, the network computer may commu- 
nicate with the smart card central processing unit 222. The 
smart card may allow for secure information to be stored in 
the smart card memory 224 in an encrypted format that can 65 
only be accessed through the smart card central processing 
unit 222. 
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Briefly, in operation, the network computer can be reboo- 
ted remotely by a network management program such as the 
Simple Network Management Protocol (SNMP) manager. 
The initialization process of the network computer includes 
performing the POST operations of the network computer 
and then accessing a network server to download a boot 
image to the network computer. The boot image may be a 
firmware update boot image. The boot image is validated by 
the network computer, and the network computer then 
executes the program code of the boot image to update the 
firmware of the network computer. A command initiated 
cold reboot of the network computer is performed and a 
second boot image is downloaded to the network computer. 
The cold boot resets the network computer as well as 
resetting the onboard peripherals of the network computer 
such as the network interface. The second boot image 
contains the standard operating system for the network 
computer. 

The present invention will now be described with refer- 
ence to FIG. 3, FIG. 4a and FIG. 4b, which are flow chart 
illustrations of the operation of a network server and a 
network computer according to the present invention. As 
seen in FIG. 3, after the network computer has downloaded 
the update boot image, the network computer attempts to 
obtain an unprocessed update record from the update boot 
image (block 300) downloaded to the network computer. 
The update boot image may contain firmware update images 
for the network computer as well as peripherals attached to 
the network computer. The firmware of each of these devices 
may be updated in a single process by including in the boot 
image multiple update images. These update images may be 
incorporated as independent records in the boot image. A 
record may contain information on how to process the 
update image to achieve the update of the firmware as well 
as the update image itself. Through the use of the informa- 
tion and the update image of a record, the firmware for the 
network computer or a particular device connected to the 
network computer may be updated. Furthermore, a list of 
update records may also be downloaded to the network 
computer so that the network computer may keep track of 
the records processed and the remaining records to process. 

After attempting to obtain an unprocessed update record 
from the download, the network computer determines if an 
unprocessed record was obtained (block 302). If an unproc- 
essed record was obtained the information contained in the 
record and the update image are utilized to update the 
firmware of the device (block 304). The network computer 
then determines if the update was successful (block 306). If 
the update was successful, then the update record is marked 
as processed (block 308) and the network computer attempts 
to obtain another unprocessed update record (block 300). 

If the update was not successful, then the network com- 
puter retries the update (block 310) and again test for success 
(block 312). If the update still fails, then the network 
computer notifies the server of the failure (block 314) and 
ends the update process. While the present invention is 
described with respect to FIG. 3 as performing a single retry, 
as will be appreciated by those of skill in the art, any number 
of retries may be attempted. 

If the network computer attempts to obtain an unproc- 
essed record (block 300) and no record is obtained (block 
302), then the update was successful as all records in the 
update download were successfully processed. The network 
computer notifies the network server of the successful 
update (block 316) and then reboots to download the stan- 
dard operating system (block 318) to complete the update 
process. 
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FIGS. 4a and 4b describe the update process including 
both server and network computer operations. As seen in 
FIG. 4a, the update process begins by the server determining 
if the network computer (NQ requires a firmware update 
(block 320). This determination may be made by obtaining 
the firmware date or revision code for the network computer. 
The firmware date or revision code may be obtained in a 
network utilizing the SNMP by the SNMP manager query- 
ing the SNMP agent resident at the network computer. 
Alternatively, if all network computers accessing a server 
are to be updated, then the server could keep track of the 
network computers which have been updated and update a 
network computer at start up if the network computer has not 
been updated. 

If the network computer is to have its firmware updated, 
then the server determines if the network computer currently 
has a user (block 322) and if the user is not absent (block 
324) waits a period of time for the user to complete using the 
network computer (block 326). Eventually, the user is no 
longer using the network computer and the network server 
installs the update boot image on the boot server for access 
by the network computer (block 328). The network server 
then issues a cold reboot command utilizing SNMP to the 
network computer (block 330). The network server then 
waits until the update boot image is downloaded by the 
network computer (block 334). Upon receiving the reboot 
command from the network server, the network computer 
reboots which causes the network computer to download the 
update boot image (block 334). As will be appreciated by 
one of skill in the are, existing program code for obtaining 
boot images as part of the initialization of a network 
computer may be utilized to download a boot image. After 
downloading the update boot image, the network computer 
validates the boot image to assure that the boot image has 
not been tampered with and is intended for the network 
computer. The validation of the update boot image may be 
carried out in the same manner as presently utilized to 
validate boot images of operating systems in network com- 
puters. Furthermore, any number of encryption and/or com- 
pression methods may be utilized so as to increase security 
of the transferred boot image and/or reduce the amount of 
data required to be transmitted to download the boot image. 

If the boot image is valid, then the network computer 
notifies the network server that the download was successful 
(block 336). When the server receives the signal from the 
network computer that the update boot image download was 
successful, the server installs the normal boot image on the 
boot server (block 338). 

Continuing on to FIG. 4b (as indicated by the connector 
"A" in FIG. 4a and the connector "A" in FIG. 4b\ the server 
then waits for the firmware update to complete at the 
network computer. The operations of the firmware update at 
the network computer are described in detail with respect to 
FIG. 3 but, for the sake of clarity certain portions are also 
illustrated in FIG. 46. As seen in FIG. 46, the network 
computer carries out the firmware update procedure (block 
342) and determines if the procedure was successful (block 
344). If the procedure was successful, then the network 
computer notifies the server of the success of the update 
(block 346), reboots and securely loads the normal operating 
system boot image (block 348). The server then receives the 
successful update signal from the network computer (block 
350) and waits for the network computer reboot (block 352). 
The server then queries the network computer to determine 
the firmware version data such as with a SNMP query (block 
354) and checks to see if the version is correct (block 356). 
If the version is correct the update process is complete, if the 
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version is not correct, then the update failed for some reason 
and the server alerts a network administrator (block 358). 

Returning to block 344, if the network computer deter- 
mines that the first attempt of the update was not successful, 

5 then the network computer retries the firmware update 
(block 360) and if that is successful (block 362) continues 
with the procedure described above. However, if the second 
attempt is also not successful, then the network computer 
notifies the server of the update failure (block 364), When 

10 the server receives the failure signal from the network 
computer (block 366), the server alerts the network admin- 
istrator of the failure (block 368) and the update process 
ends. 

The present invention has been described with respect to 

15 a single network computer being updated by a single net- 
work server, however, as will be appreciated by those of skill 
in the art, the present invention is equally applicable to 
numerous network computers being remotely updated by a 
centralized network administrator. The use of the remote 

20 cold reboot process further allows for multiple network 
computers and the peripherals attached to those computers 
to be updated without intervention at each individual net- 
work computer. 

25 As used herein, the term network computer refers to any 
data processing system which boots from a network server. 

In the drawings and specification, there have been dis- 
closed typical preferred embodiments of the invention and, 
although specific terms are employed, they are used in a 

3 q generic and descriptive sense only and not for purposes of 
limitation, the scope of the invention being set forth in the 
following claims. 

That which is claimed: 

1. A method of updating firmware in a network computer, 
35 which initializes using a boot image comprising a standard 

operating system on a network server, the method compris- 
ing: 

detecting, at the network server, whether the network 
computer firmware is to be updated; 
40 performing the following steps if the network server 
detects that the network computer firmware is to be 
updated: 

replacing, at the network server, the standard operating 
system to be loaded at the initialization of the 
45 network computer with a firmware update operating 

system; then 

downloading the firmware update operating system to 
the network computer at initialization of the network 
computer; then 

50 initiating the firmware update operating system to 
update the firmware of the network computer. 

2. A method according to claim 1, further comprising the 
step of replacing, at the network server, the firmware update 
operating system with the standard operating system to be 

55 loaded at the initialization of the network computer. 

3. A method according to claim 2, wherein said step of 
replacing the firmware update operating system comprises 
the step of reinitializing the network computer so as to load 
the standard operating system. 

60 4. A method according to claim 2, wherein said step of 
replacing, at the network server, the standard operating 
system to be loaded at the initialization of the network 
computer with a firmware update operating system com- 
prises the step of replacing the boot image for the standard 

65 operating system with a firmware update boot image, and 
wherein said step of replacing the firmware update operating 
system with the standard operating system comprises the 
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step of replacing the firmware update boot image with the 
standard operating system boot image. 

5. A method according to claim 1, further comprising the 
step of validating the firmware update operating system 
prior to the step of initiating the firmware update operating 5 
system. 

6. A method according to claim 1, wherein said step of 
replacing, at the network server, the standard operating 
system to be loaded at the initialization of the network 
computer with a firmware update operating system com- JQ 
prises the step of replacing, at the network server, the boot 
image for the standard operating system with a firmware 
update boot image. 

7. A method according to claim 1, wherein said firmware 
update operating system updates the firmware of a device 
attached to the network computer. 15 

8. A method according to claim 1, wherein said detecting 
step comprises the step of sending an SNMP query to an 
SNMP agent resident on the network computer. 

9. A method according to claim 1, wherein the firmware 
update operating system causes the update of a plurality of 20 
devices. 

10. A method according to claim 1, wherein said step of 
reinitializing the network computer comprises the step of 
initiating a cold reboot of the network computer. 

11. A system for updating firmware in a network 2 s 
computer, which initializes using a boot image comprising a 
standard operating system on a network server, comprising: 

means for detecting, at the network server, whether the 
network computer firmware is to be updated; 

means for replacing the standard operating system to be 30 
loaded at the initialization of the network computer 
with a firmware update operating system; 

means for downloading the firmware update operating 
system to the network computer at initialization of the 
network computer; and 35 

means for initiating the firmware update operating system 
to update the firmware of the network computer; 

wherein the means for replacing the standard operating 
system, the means for downloading the firmware 
update operating system, and the means for initiating 40 
the firmware update operating system are operably 
associated with the means for detecting so as to only 
update the network computer firmware if the means for 
detecting detects that the network computer firmware is 
to be updated. 45 

12. A system according to claim 11, further comprising 
means for replacing the firmware update operating system 
with the standard operating system to be loaded at the 
initialization of the network computer. 

13. A system according to claim 12, wherein said means 50 
for replacing the firmware update operating system com- 
prises means for reinitializing the network computer so as to 
load the standard operating system. 

14. A system according to claim 12, wherein said means 
for replacing the standard operating system to be loaded at 55 
the initialization of the network computer with a firmware 
update operating system comprises means for replacing the 
boot image for the standard operating system with a firm- 
ware update boot image, and wherein said means for replac- 
ing the firmware update operating system with the standard 60 
operating system comprises means for replacing the firm- 
ware update boot image with the standard operating system 
boot image. 

15. A system according to claim 11, further comprising 
means for validating the firmware update operating system 65 
prior to the initialing of the firmware update operating 
system. 
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16. A system according to claim U, wherein said means 
for replacing the standard operating system to be loaded at 
the initialization of the network computer with a firmware 
update operating system comprises means for replacing the 
boot image for the standard operating system with a firm- 
ware update boot image. 

17. A system according to claim 11, wherein said firm- 
ware update operating system updates the firmware of a 
device attached to the network computer. 

18. A system according to claim 11, wherein the firmware 
update operating system causes the update of a plurality of 
devices. 

19. A system according to claim 11, wherein said means 
for reinitializing the network computer comprises means for 
initiating a cold reboot of the network computer. 

20. A computer program product for updating firmware in 
a network computer, which initializes using a boot image 
comprising a standard operating system on a network server, 
the computer program product comprising: 

a computer-readable storage medium having computer- 
readable program code means embodied in said 
medium, said computer-readable program code means 
comprising: 

computer-readable program code means for detecting, 
at the network server, whether the network computer 
firmware is to be updated, 

computer- readable program code means for replacing 
the standard operating system to be loaded at the 
initialization of the network computer with a firm- 
ware update operating system; 

computer- readable program code means for download- 
ing the firmware update operating system to the 
network computer at initialization of the network 
computer; and 

computer-readable program code means for initiating 
the firmware update operating system to update the 
firmware of the network computer; 

wherein the computer- read able program code means 
for replacing the standard operating system, the 
computer- readable program code means for down- 
loading the firmware update operating system, and 
the computer-readable program code means for ini- 
tiating the firmware update operating system are 
operably associated with the computer- readable pro- 
gram code means for detecting so as to only update 
the network computer firmware if the computer- 
readable program code means for detecting detects 
that the network computer firmware is to be updated. 

21. A computer program product according to claim 20, 
further comprising computer-readable program code means 
for replacing the firmware update operating system with the 
standard operating system to be loaded at the initialization of 
the network computer. 

22. A computer program product according to claim 21, 
wherein said computer-readable program code means for 
replacing the firmware update operating system comprises 
computer-readable program code means for reinitializing the 
network computer so as to load the standard operating 
system. 

23. A computer program product according to claim 21, 
wherein said computer-readable program code means for 
replacing the standard operating system to be loaded at the 
initialization of the network computer with a firmware 
update operating system comprises computer-readable pro- 
gram code means for replacing the boot image for the 
standard operating system with a firmware update boot 
image, and wherein said computer-readable program code 
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means for replacing the firmware update operating system 
with the standard operating system comprises computer- 
readable program code means for replacing the firmware 
update boot image with the standard operating system boot 
image. 

24. A computer program product according to claim 20, 
further comprising computer-readable program code means 
for validating the firmware update operating system prior to 
the initiating of the firmware update operating system. 

25. A computer program product according to claim 20, 
wherein said computer-readable program code means for 
replacing the standard operating system to be loaded at the 
initialization of the network computer with a firmware 
update operating system comprises computer-readable pro- 
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gram code means for replacing the boot image for the 
standard operating system with a firmware update boot 
image. 

26. A computer program product according to claim 20, 
wherein said firmware update operating system updates the 
firmware of a device attached to the network computer. 

27. A computer program product according to claim 20, 
wherein said computer-readable program code means for 
reinitializing the network computer comprises computer- 
readable program code means for initiating a cold reboot of 

30 the network computer. 

28. A computer program product according to claim 20, 
wherein the firmware update operating system causes the 
update of a plurality of devices. 

***** 
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ABSTRACT 



A method of loading a program, wherein a relative address 
format file is transformed into a program format including a 
set of records each having an instruction and instruction 
relocation information, and wherein a loader receives the 
records one by one from a file of the above-mentioned 
program format, transforms the relative format program into 
an absolute address format program, and loads the absolute 
address formal program on the memory. 

30 Claims, 15 Drawing Sheets 
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METHOD FOR LOADING A PROGRAM 

This application makes reference to, incorporates the 
same herein, and claims all benefits accruing under 35 
U.S.C. § 119 from an application for "Method For Loading 
A Program," earlier filed in Japan on Sep. 12, 1997, Serial 
No.9-248745, a copy of which application is annexed 
hereto. 

BACKGROUND OF THE INVENTION 

The present invention relates to a method for loading a 
program, and more particularly to a method for generating 
an absolute address program from a relative address pro- 
gram and loading the absolute address program into 
memory. In addition, the present invention relates to a 
computer software product, such as a computer-readable 
medium, that contains the above-mentioned method for 
loading a program. 

TWo types of program object codes are absolute address 
codes and relative address codes. Absolute address codes are 
instructions that use absolute addresses when referring to 
data in memory or designating branch destinations. Pro- 
grams that CPU's can execute directly are programs written 
using absolute addresses. 

Relative address codes are instructions that designate 
memory addresses or branch destinations by using relative 
addresses such as symbolic addresses. Since CPU's cannot 
execute a program which is written using relative addresses, 
a relative address program is converted into an absolute 
address program through a loader prior to execution by the 
CPU. Unlike the absolute address programs, it is possible to 
specify storage locations for relative address programs when 
they are loaded into memory. Relative address format pro- 
grams are currently used in many computers because it is 
possible to freely select storage locations in memory for the 
relative address format programs. 

A relative address format program file includes a program 
proper and relocation information. Relocation information is 
information that is referred to by the loader when converting 
a relative address format program into an absolute address 
format program. This is outlined in Chapter 5, Loader, 
particularly in Sub-chapter 5.1.5, Relocating Loader, pp. 
170-174 of System Program I by John J. Donovan, 1976, 
published by Nippon Computer Kyokai. The most common 
of the program file formats is COFF (Common Object File 
Format), a detailed description of which, is given in Chapter 
4, File Formats a. Out (4), pp. 1-2 of AT&T UNIX SYSTEM 
V Programmers Reference Manual, 1990. 

SUMMARY OF THE INVENTION 

The loader for relocating a relative address format file 
reads the whole file, maps the file on a memory, and converts 
the relative address format file into an absolute address 
format file. A relative address format file, including reloca- 
tion information, is often several times the size of an 
absolute address format file. Therefore, to enable the loader 
to operate, it is necessary to procure a working storage area 
several times larger than the whole program. If such a 
working storage area cannot be secured, the loader cannot 
load the program file, and the CPU cannot execute the 
program. It is an object of the present invention to provide 
a method for loading or executing a program, even if the 
system involved does not have a memory resource sufficient 
to map a relative address format file in the memory. 

To achieve the above object, the method for loading a 
program according to an aspect of the present invention 
comprises the steps of: 
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(1) converting a conventional relative address format file 
into a file of a program format having a set of records, 
each made up of an instruction and instruction reloca- 
tion information; 
5 (2) having the loader fetch records one by one from a file 
of a program format generated in step (1), transform the 
file into an absolute address format, and locate or 
dispose the file on the memory; 

(3) when the file of the program format generated accord- 
10 ing to step (1) cannot be stored in a single medium, 

dividing the file into smaller files and storing them in a 
plurality of media; and 

(4) having the loader sequentially load the smaller files, 
divided according to step (3), and locate them on the 

15 memory by rearranging them into a single program. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram showing an example of a system 
to which the present invention is applied; 
20 FIG. 2 is a diagram showing the procedure of a method of 
loading a program; 

FIG. 3 is a diagram showing a relative address format file; 
FIG. 4 is a diagram showing a sequentially transformable 
relative address format file in which one record is created for 
25 each piece of relocation information. 

FIG. 5 is a diagram showing an example of dividing a 
sequentially transformable relative address format file in 
which records are created one record for each piece of 
relocation information; 
30 FIG. 6 is a flowchart showing a file transformation 
procedure for creating a sequentially transformable relative 
address format file in which one record is created for each 
piece of relocation information or is a medium portion 
which stores therein a program for implementing the flow- 
35 chart; 

FIG. 7 is a flowchart showing a loader procedure for 
locating a sequentially transformable format file in which 
one record is created for each piece of relocation informa- 
tion or is a medium portion which stores therein a program 

40 for implementing the flowchart; 

FIG. 8 is a diagram showing a sequentially transformable 
relative address format file in which one record is created for 
each instruction; 

45 FIG. 9 is a diagram showing an example of division of a 
sequentially transformable relative address format file in 
which one record is created for each instruction; 

FIG. 10 is a flowchart showing a file transformation 
procedure for creating a sequentially transformable relative 

50 address format file in which one record is created for each 
instruction or is a medium portion which stores therein a 
program for implementing the flowchart; 

FIG. 11 is a flowchart showing a loader procedure for 
locating a sequentially transformable relative address format 

55 file in which one record is created for each instruction or is 
a medium portion which stores therein a program for imple- 
menting the flowchart; 

FIG. 12 is a diagram showing a memory image of 
executable codes with relocation information on the system; 

60 FIG. 13 is a flowchart showing a procedure of loading a 
program into another system from the memory image of 
executable codes with relocation information or is a medium 
portion which stores therein a program for implementing the 
flowchart; 

65 FIG. 14 is a diagram illustrating the method of loading a 
program, including the steps of setting a condition for access 
permission and for performing an encryption process; and 
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FIG. 15 is a block diagram showing a system configura- 
tion for loading an application program from a terminal 
device. 

DESCRIPTION OF THE PREFERRED 

EMBODIMENTS 5 

FIG. 1 is a block diagram showing an example of a system 
to which the present invention is applied. Reference numeral 
11 denotes a computer system or an IC card terminal system. 
An IC card 19 is inserted into an IC card reader (not shown). 30 
This terminal system 11 includes a microcomputer chip 12, 
a flash memory 14, a card interface (IFD) 15, a liquid crystal 
panel (LCP) display 16, and a key pad 17, and those 
component parts are interconnected by a common bus 18. 
The microcomputer chip 12 includes a RAM 13 as a 15 
working storage. The flash memory 14 contains an applica- 
tion program and data. The card interface (IFD) 15 com- 
municates with the IC card. The liquid crystal panel 16 
shows data such as the balance and menus. The key pad 17 
accepts key inputs by the user. The user operates the keys to 2 q 
input instructions and, data, and in response to the 
instructions, the terminal communicates with the IC card 
and executes a necessary process. The result of the process 
is displayed on the liquid crystal panel (LCP) display 16. 

FIG. 2 is a diagram showing an example of process steps 2 s 
of the program loading method according to the present 
invention. Computers having an external storage device, 
such as a disk device or an IC card, to carry out the program 
loading method according to the present invention. A file 
transformation process 101 accepts a relative address format 30 
file 100 as an input, and outputs a sequentially transformable 
relative address format file 104. A sequentially transform- 
able relative address format file 104 can be stored in a disk, 
an IC card, or any other recording medium. If the file cannot 
be fully accommodated in a single medium, the file may be 35 
divided and stored in a plurality of media. 

A common type of relative address format files is COFF 
(Common Object File Format). The sequentially transform- 
able relative address format file 104 is a file of a format 
which includes a set of records, each made up of an 40 
instruction and instruction relocation information. The file 
transformation process 101 first creates records by a record 
creation process 102. There are two record creation meth- 
ods: a method of creating records by which one record is 
created for each piece of relocation information and a 45 
method of creating records by which one record is created 
for each instruction. The file transformation process 101 
collects the created records and outputs them to a file. If the 
file cannot be stored in a single medium, the file division 
process 103 divides the file into a plurality of operation 50 
units, in other words, files. When an IC card is used to store 
a file, since its recording capacity is limited, it often becomes 
necessary to divide the file. 

A sequentially relocating loader 105 reads a sequentially 
transformable relative address format file 104 (110), and 55 
outputs an absolute address format program. The absolute 
address format program can be directly located in memory 
and executed. The program may be written directly in 
memory or may be stored in a file. If there are a number of 
input files, the sequentially relocating loader performs a 60 
sequential loading process, thereby transforming those files 
into a single absolute address format program and outputting 
the program. The sequentially relocating loader 105 first 
reads the file header and decides instruction relocation 
addresses (106). On the basis of the addresses, the loader 65 
105 executes a record relocation process (107), and gener- 
ates an absolute address format program 108. 
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FIG. 3 shows an example of an object file of relative 
address format. This example is for purposes of illustration 
and, is shown in a simpler form than general COFF format 
files. A relative address format file 200 roughly consists of 
three major sections: a file header 201, a code block or field 
202, and a relocation information block or field 207. Infor- 
mation written in the file header 201 is information on the 
attributes, the layout of areas and the like of the file. The 
code block 202 shows a string of instructions 203, 204, 205 
and 206. Some instructions are subject to the relocation 
process, and others are not subject to the relocation process. 
Instructions 204 and 205 are non-relocation instructions. 
The instructions written in the code block are used as 
absolute address instructions as they are. Instructions 203 
and 206 are subject to relocation and are transformed into 
absolute address instructions during loading according to 
relocation information 208 and 209. 

There are two possible file formats of the sequentially 
transformable relative address format. First there will be 
discribed a method of creating records by which one record 
is created for each instruction; then a method of creating 
records by which one record is created for each piece of 
relocation information will be explained. 

FIG. 4 shows an example of a sequentially transformable 
relative address format file 300, in which one record is 
created for each piece of relocation information. A file 300 
consists of a file header 301 and a record list 302. In the file 
header 301, file identification information and an offset for 
locating the record are written. The record list 302 has a 
plurality of records 303, 304 and so on, arranged sequen- 
tially. 

Records 303, 304 each includes relocation information, a 
corresponding instruction to be relocated, and an instruction 
involving no relocation. Each record always includes a piece 
of relocation information and an instruction to be relocated. 
However, the record may not include an instruction involv- 
ing no relocation or may include a plurality of instructions 
involving no relocation. The record 303 includes relocation 
information 208, an instruction to be relocated 203, and two 
instructions involving no relocation 204, 205. On the other 
hand, the record 304 includes relocation information 209 
and an instruction to be relocated 206, but no instruction 
involving no relocation. 

Because each record holds therein relocation information 
and an instruction to be relocated, the moment the loader 
reads a record, it can locate or dispose of the record 
immediately. 

FIG. 5 shows examples of dividing a file into sequentially 
transformable relative address format files 400, 403, in 
which one record is created for each piece of relocation 
information. A sequentially transformable relative address 
format file can be divided into an arbitrary number of files, 
one file for each record list. The record list 302 in FIG. 4 is 
divided into a record list 402 and a record list 403, those lists 
402 and 403 being respectively the components of a file 400 
(file 1) and a file 403 (file 2). 

Each file header includes file identification data and an 
oflket in the code block. In a file header 401, however, only 
file identification information is written. Since the file 400 is 
the starting file, the instructions need to be located at the 
leading end of the code block. In a file header 404, file 
identification information and a code offset are written. In 
the file 403, which is the second file, the instructions need to 
be located in memory with a space for instructions of the 
start file left empty. From the header 404, it is understood 
that the instructions need to be located starting at a point 16 
bytes from the leading end of the code block. 
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FIG. 6 shows a medium portion 101 that stores therein a 
program for implementing a procedure of the file transfor- 
mation process for creating a sequentially transformable 
relative address format file, in which one record is created 
for each piece of relocation information. Steps 500 to 504 
correspond to the record creation process 102 in FIG. 2. 
Steps 505 to 507 correspond to the file division process in 
FIG. 2. First, at Step 500, a relative address format file is 
read and loaded into the flash memory 14. Then, at Step 501, 
a relocation information block 207 is inspected to check the 
number of entries of relocation information. As many 
records of sequentially transformable relative address for- 
mat are created as the number of entries. At Step 502, the 
entry in the relocation information field in each record is 
scanned, and relocation information is written in the record 
of the sequentially transformable relative address format. 

Subsequently, the instructions in the code block 202 are 
written in the records. At this time, there is a difference in 
handling between the instructions to be relocated and the 
instructions involving no relocation. At Step 503, the 
instructions to be relocated are written in records, one 
instruction in each record. At Step 504, the instructions 
involving no relocation, which are disposed of after the 
written instruction to be located and before the next instruc- 
tion to be relocated, are written in the same record where the 
immediately preceding instruction to be relocated has been 
written. Consequently, in some cases, a plurality of instruc- 
tions involving no relocation are written in a record; and, in 
other cases, no instruction involving no relocation is written 
in a record. 

At Step 505, the size of the resulting sequentially trans- 
formable relative address format file is estimated. Since the 
size of the file header is fixed, the size of the whole file can 
be estimated from the size of the storage area of the memory 
that the records occupy. If the size of the file is less than the 
storage capacity of the recording medium, the file is treated 
as a single file. When the file is larger than the storage 
capacity of the recording medium, the record list is divided 
into a number of files at Step 508. At Step 507, an 
instruction-offset value is calculated for each file if 
necessary, and file headers are generated. Finally, at Step 
508, records are written sequentially in the files. 

For confidential programs, at Step 507, a condition for 
access permission is written in the file header. At Step 508, 
the records are first encrypted and then written in a file. 
Records may be encrypted separately, or the whole record 
list may be encrypted collectively. The general configuration 
for setting a condition for access permission or for perform- 
ing an encryption process will be described later with 
reference to FIG. 14. 

FIG. 7 shows a medium portion 105 that stores therein a 
program for implementing a procedure of the sequentially 
relocating loader for locating a sequentially transformable 
relative address format file, in which one record is created 
for each piece of relocation information. Steps 600 and 601 
correspond to the instruction relocation address decision 106 
in FIG. 2, and Steps 602 to 608 correspond to the record 
relocation process 107 in FIG. 2. At Step 600, a sequentially 
relocatable relative address format file header is read. At 
Step 601, the attributes of the file are referred to. If access 
permission information has been added to the file header, the 
access permission condition is checked; and, if the permis- 
sion condition is satisfied, the process continues. After this, 
a check is made to see if the file has been divided. If the file 
is still a single file, the process continues. If the file has been 
divided into a plurality of files, the instruction offsets of 
those files are checked. In the subsequent record relocation 
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process 107, the instructions are relocated to locations that 
are separated by offset values from the reference point in the 
code block. This makes it possible to read the divided files 
into memory in arbitrary sequence. 

At Step 602, the records are scanned sequentially. If the 
records have been encrypted, they are decrypted here. When 
all the records have been scanned, the record relocation 
process is completed. At Step 603, the relocation informa- 
tion of the record is fetched. Then, at Step 604, the instruc- 
tion to be relocated is fetched. At Step 605, from this 
instruction and the relocation information that has been 
previously read, an absolute address instruction is generated, 
and the generated instruction is located or disposed in the 
code block in the memory. Then, at Step 606, a check is 
made to see if there is any instruction involving no reloca- 
tion. If there is no instruction involving no relocation in the 
record, the process proceeds to the next record. However, if 
an instruction involving no relocation is included in the 
record, the instruction is written in the code block in the 
memory by performing Steps 607 and 608. After the instruc- 
tion has been written in the memory, the process moves on 
to the next record. 

After the process is finished, the relocation information in 
the code block in the memory is checked. If the file remains 
a single file, the instructions have been relocated in all the 
code blocks, and the system is notified that the program 
ready for execution is. However, if a file was divided into 
smaller files, the instructions have not necessarily been 
relocated in all the code blocks. After it has been confirmed 
that all instructions were relocated, notification that the 
program is in ready condition is given to the managing 
program of the system. 

A file 700 in FIG. 8 is an example of a sequentially 
transformable relative address format file, in which one 
record is created for each instruction. The file 700 includes 
a file header 701 and a record list 702. In the file header 701, 
file identification information and an offset for locating the 
record are written. The record list 702 is a list of records 703, 

704, 705, 706 and so on, arranged sequentially. 

A record includes relocation information and an instruc- 
tion. If the instruction is an instruction to be relocated, the 
record includes relocation information and an instruction. 
On the other hand, if the instruction is an instruction 
involving no relocation, the relocation information becomes 
null. In the records 703 and 706, because the instructions 
203 and 206 are instructions to be relocated, they each have 
relocation information 208 and 209. In the records 704 and 

705, because the instructions 204 and 205 are instructions 
involving no relocation, there is no relocation information 
for those instructions. 

Each record holds therein information necessary for relo- 
cation. Therefore, on reading a record, the loader can 
immediately locate or dispose of the instruction. 

FIG. 9 shows an example of division of the sequentially 
transformable relative address format file of FIG. 8 into files 
800 and 803, in which one record is created for each 
instruction. The sequentially transformable relative address 
format file can be divided into an arbitrary number of files, 
one file for each record list. The record list 702 in FIG. 8 is 
divided into a record list 802 and a record list 805 in FIG. 
9, the record lists 802 and 805 being respectively the 
components of a file 800 (file 1) and a file 802 (file 2). 

Each file header stores file identification information and 
a code offset in the code block. In a file header 801, however, 
only file identification information is written. Because the 
file 800 is the starting file, the instructions are to be located 
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at the beginning of the code block. In a file header 804, file 
identification information and a code offset are written. 
Since the file 803 is the second file, when locating the 
instruction of the second file 403, it is necessary to leave a 
space for the instructions of the first file. From the file header 
804, it is understood that the instructions need to be located 
starting at a point 16 bytes from the leading end of the code 
block. 

FIG. 10 shows a medium portion 101 that stores therein 
a program for implementing a procedure of the file trans- 
formation process for creating a sequentially transformable 
relative address format file, in which records are created at 
the rate of one record for each instruction. Steps 900 to 904 
correspond to the record creation process 102 of FIG. 2. 
Steps 905 to 908 correspond to the file division process 103 
of FIG. 1. At Step 900, a relative address format file is read 
and loaded into the flash memory 14. At Step 901, the code 
block is checked, the number of instructions is checked, and 
as many records as the number of instructions are created. At 
Step 902, an instruction is entered in the created record. At 
Step 903, the entry in the relocation information field is 
scanned to see if there is relocation information correspond- 
ing to the instruction. If there is no relocation information 
corresponding to the instruction, it follows that the instruc- 
tion is an instruction involving no relocation. Therefore, the 
field for relocation information is left empty. If there is 
relocation information corresponding to that instruction, it 
follows that the instruction is an instruction to be relocated. 
At Step 904, relocation information is written in the relo- 
cation information field of the record. 

When all instructions have been written in the record, the 
size of the sequentially transformable relative address for- 
mat file is estimated at Step 905. Since the size of the file 
header is fixed, the size of the whole file can be estimated by 
finding that storage size of memory which is occupied by the 
records. If the file size is within the storage size of a medium 
in which the file is written, the file is treated as a single file. 
If the file cannot be fully stored in the medium, however, the 
file is divided into a plurality of smaller files at Step 906. The 
instruction-offset value for each file is calculated, and file 
headers are created at Step 907. Finally, the records are 
written in the files at Step 908. 

For confidential programs, at Step 907, a condition for 
access permission is written in the file header. At Step 908, 
the records are first encrypted and then written in the file. 
Records may be encrypted individually or the whole record 
list may be encrypted collectively. The general configuration 
for setting a condition for access permission or for perform- 
ing an encryption process will be is described with reference 
to FIG. 1. 

FIG. 11 shows a medium portion 105 that stores therein 
a program for implementing the procedure of the sequen- 
tially relocating loader for relocating a sequentially trans- 
formable relative address format file, in which one record is 
created for each instruction. Steps 1000 and 1001 corre- 
spond to the instruction relocation address decision 106 in 
FIG. 2, and Steps 1002 to 1007 correspond to the record 
relocation process 107 in FIG. 2. At Step 1000, the file 
header is read. At Step 1001, the attribute s of the file are 
referred to. If access permission information is added in the 
file header, the access permission condition is checked. If the 
condition is satisfied, the process continues. Then the file is 
checked to see if it has been divided. If the file remains a 
single file, the process continues. If a file has been divided 
into a plurality of smaller files, the instruction offsets of 
those files are checked. In the subsequent process 107, 
instructions are located at locations that are separated by 
offset values from the reference point in the code block. 
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Subsequently, at Step 1002, records are scanned sequen- 
tially. If the records, have been encrypted, they are decrypted 
here. When all records have been scanned, the process 107 
is completed. At Step 1003, the record is inspected to see if 

5 relocation information has been written. If there is no 
relocation information, the instruction is written as is in the 
code block at Step 1003. If there is relocation information, 
the relocation information is read at Step 1005, and an 
instruction to be relocated is read at Step 1006. At Step 1007, 

30 from the relocation information and the instruction to be 
relocated, an instruction at an absolute address is generated, 
and the generated instruction is written in the code block in 
the memory. 

After all records have gone through the above the process, 
35 the relocation information in the code block in the memory 
is checked. If the file remains a single file, the instructions 
must have been relocated to absolute addresses in all of code 
blocks. Notification that the program is now in executable 
condition is given to the manager of the system. If the file 
20 has been divided into smaller files, the instructions have not 
necessarily been relocated in all the code blocks. When it has 
been confirmed that all files are loaded and the instructions 
are relocated in all of the code blocks, notification that the 
program is ready for execution is given the manager of the 
25 system. 

FIG. 12 is a diagram showing a memory image of 
executable codes with relocation information. The whole 
program has been transformed into an absolute address 
format ready for operation and loaded on the memory. Once 

30 the program has been transformed into an absolute address 
format, the relocation information is lost, so that the relo- 
cation process cannot be performed further. In anticipation 
of future relocation, relocation information must be stored in 
another storage area. 

An area 1101 shows a memory image on the system. An 
area 1103 denotes a code block of an executable application 
program. Areas 1104, 1105, 1106 and 1107 denote instruc- 
tions in the code block. An area 1109 denotes a storage block 

4Q for storing relocation information for the instructions. The 
instructions 208 and 209 constitute relocation information. 
An area 2220 denotes a storage block for storing information 
other than relocation information. The areas 1109 and 1110 
are not required for execution of the instructions, but they 

45 are used when the program in the code block 1103 is 
relocated and loaded to another system. 

An area 1102 is a system block, and an area 1111 is a 
block for storing another application program. 

FIG. 13 shows a medium portion that stores therein a 

50 program for implementing a procedure for loading to 
another terminal a program from the memory image of 
executable codes added with relocation information shown 
in FIG. 12. At Step 1201, the code block in the memory of 
the sending terminal is checked. If there is no instruction, the 

55 procedure is terminated. If there is an instruction, the 
instruction is fetched at Step 1202, and the relocation 
information block is checked for relocation information 
corresponding to the instruction at Step 1203. If there is no 
relocation information, at Step 1205, the instruction is 

60 transferred to the terminal to which the program is loaded. 
If there is relocation information, at Step 1204, the reloca- 
tion process is performed. After the process is finished, the 
instruction is transferred to the destination terminal at Step 
1205*. 

65 After the instruction has been transferred, the process 
proceeds to Step 1206. When necessary, a command is 
issued directing that the program, which has been loaded to 
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the one other terminal, be loaded to yet another terminal. If 
a command to load the program to another terminal is not 
issued, the process is terminated. When the program is 
loaded to yet another terminal, relocation information is 
required. At Step 1207, relocation information is transferred 5 
to the terminal as the loading destination. 

FIG. 14 shows a general configuration of a procedure 
including the processes of setting a condition for access 
permission and for performing an encryption process. These 
processes are preceded by a common basic procedure. After 10 
main steps of file transformation are finished, a permission 
condition writing process 1401 is first conducted, followed 
by an encryption process 1402. 

If a permission condition has been set or encryption has 
been done in a sequentially transformable relative address 35 
format file 104, other processes must precede the main 
relocation process. More specifically, a decryption process 
1403 is executed to make the contents of the file readable. 
Then, a permission condition reading process 1404 is 
executed to confirm the permission condition. If the permis- 20 
sion condition is satisfied, the process continues. If not, the 
process is terminated. From the sequentially relocating 
loader on, the same basic procedure is performed. 

FIG. 15 shows an example of a system configuration for 
loading an application program from a terminal by applying 25 
the procedure in FIG. 13. Both terminals 1501 and 1502 are 
identical to the earlier-described terminal 11. In this 
example, the application program is loaded from the termi- 
nal 1501 to the terminal 1502. A flash memory 14 in the 
terminal 1501 contains an application program of a format 30 
of the memory image for executable codes accompanied by 
relocation information in FIG. 12. A microcomputer 12 in 
the terminal 1501 executes the loading procedure shown in 
FIG. 13 to generate an application program that can be 
loaded directly. The terminal 1502 receives the application 
program from the terminal 1501 and writes it into its own 
flash memory 14. 

There are many methods for connecting terminals. In the 
example shown in FIG. 15, the slots for IC cards are utilized 4Q 
for communication between terminals. Communication con- 
nectors for loading may be provided separately. Application 
programs can be loaded by infrared communication or radio 
communication. 

The above-mentioned processes and steps according to 45 
the present invention can be embodied in computer software 
programs, including computer readable media, such as a 
CD-ROM and a floppy disk. 

According to the above-mentioned embodiment, a pro- 
gram can be loaded or executed in a system without memory 50 
resources sufficient to load a relative address format file into 
the memory (memory 13 in FIGS. 1 and 15). 

What is claimed is: 

1. A method of loading a program comprising the steps of: 
when reading a sequentially transformable relative 55 

address format program, including a set of records each 
record having an instruction and instruction relocation 
information corresponding to said instruction, sequen- 
tially relocating instructions by reading said records of 
said sequentially transformable relative address format 60 
program one by one to thereby generate an absolute 
address format program. 

2. A method according to claim 1, further comprising the 
step of mapping said absolute address format program, 
which has been generated, on a memory. 65 

3. A method according to claim 1, wherein said sequen- 
tially transformable relative address format program con- 
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tains a header including access permission information, and 
if said access permission information is satisfied, instruc- 
tions are relocated sequentially by reading said records one 
by one to generate said absolute address format program. 

4. A method according to claim 1, wherein said sequen- 
tially transformable relative address format program is 
stored in an IC card, and when loaded into memory, said 
records of said sequentially transformable relative address 
format program are read one by one from said IC card for 
sequential relocation to generate said absolute address for- 
mat program. 

5. A method of loading a program comprising the steps of: 
transforming a first relative address format program 

including an instruction string and relocation informa- 
tion into a second relative address format program 
including a set of records each record having an 
instruction and instruction relocation information cor- 
responding to said instruction; and 
sequentially relocating instructions by reading said 
records of said second relative address format program 
one by one to thereby generate an absolute address 
format program. 

6. A method according to claim 5, further comprising the 
step of storing a header having an access permission con- 
dition set therein said second relative address format 
program, and when said access permission condition is 
satisfied, said instructions are relocated sequentially by 
reading said records of said second relative address format 
program one by one to generate said absolute address format 
program. 

7. A method according to claim 5, further comprising the 
step of storing a header having attributes information set 
therein said second relative address format program. 

8. A method according to claim 5, further comprising the 
step of storing said second relative address format program 
in at least one IC card, wherein said second relative address 
format program is loaded into memory by sequentially 
relocating said instructions and reading said records of said 
second relative address format program one by one from 
said IC card. 

9. A method of loading a program comprising the steps of: 
transforming a first relative address format program 

including an instruction string and relocation informa- 
tion into a second relative address format program 
including a set of records each record having an 
instruction and instruction relocation information cor- 
responding to said instruction; 

dividing said second relative address format program into 
a plurality of storage units; and 

storing said plurality of storage units in storage media. 

10. A method according to claim 9, further comprising the 
step of sequentially relocating instructions by reading said 
records of said second relative address format program one 
by one to thereby generate an absolute address format 
program. 

11. A method according to claim 10, further comprising 
the step of mapping said absolute address format program, 
which has been generated, on a memory. 

12. A method of loading a program comprising the steps 

of: 

transforming a first address format program including an 
instruction string and relocation information into a 
second relative address format program including a set 
of records each record having an instruction and 
instruction relocation information corresponding to 
said instruction; 
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dividing said second relative address format program into 
a plurality of storage units; 

providing each storage unit with a header having set 
therein relocation information; and 

loading said plurality of storage units on a memory by 5 
reading said storage units in an optional sequence, and 
sequentially relocating said instructions by reading said 
records of said second relative address format program 
one by one according to relocation information in the 
header of each storage unit that has been loaded. 10 

13. A method of loading a program comprising the steps 

of: 

when reading a sequentially transformable relative 
address format program, including a set of encrypted ]5 
records each encrypted record having an instruction 
and instruction relocation information corresponding to 
said instruction, sequentially relocating instructions by 
reading and decrypting said encrypted records of said 
sequentially transformable relative address format pro- 2Q 
gram one by one to thereby generate an absolute 
address format program. 

14. A method according to claim 13, wherein said sequen- 
tially transformable relative address format program con- 
tains a header including access permission information, and 25 
if said access permission information is satisfied, instruc- 
tions are relocated sequentially by reading said records one 
by one to generate said absolute address format program. 

15. A method according to claim 13, wherein said sequen- 
tially transformable relative address format program is 3Q 
stored in an IC card, and when loaded into memory, said 
records of said sequentially transformable relative address 
format program are read one by one from said IC card for 
sequential relocation to generate said absolute address for- 
mat program. 35 

16. A method of loading a program comprising the steps 

of: 

transforming a first relative address format program 
including an instruction string and relocation informa- 
tion into a second relative address format program 40 
including a set of records having a group of instructions 
including instruction relocation information and at least 
one instruction corresponding to said relocation infor- 
mation; and 

sequentially relocating instructions by reading said 45 
records of said second relative address format program 
one by one to thereby generate an absolute address 
format program. 

17. A method according to claim 16, wherein said second 
relative address format program contains a header including 50 
access permission information, and if said access permission 
information is satisfied, instructions are relocated sequen- 
tially by reading said records one by one to generate said 
absolute address format program. 

18. A method according to claim 16, wherein said sequen- 55 
tially transformable relative address format program is 
stored in an IC card, and when loaded into memory, said 
records of said sequentially transformable relative address 
format program are read one by one from said IC card for 
sequential relocation to generate said absolute address for- go 
mat program. 

19. A computer software product including a computer 
readable medium, said computer readable medium having 
stored thereon: 

a first code section for holding a sequentially transform- 65 
able relative address format program including a set of 
records each record having an instruction and instruc- 
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tion relocation information corresponding to said 
instruction, and for having said relative address format 
program read into a computer; and 
a second code section for generating an absolute address 
format program by sequentially relocating instructions 
and reading said records of said relative address format 
program one by one. 

20. A computer software product according to claim 19, 
wherein said computer readable medium is further stored 
thereon: 

a third code section for loading said absolute address 
format program, which has been generated, on a 
memory. 

21. A computer software product including a computer 
readable medium, said computer readable medium having 
stored thereon: 

a code section for transforming a first address format 
program including an instruction string and relocation 
information into a second relative address format pro- 
gram including a set of records each record having an 
instruction and instruction relocation information cor- 
responding to said instruction; and 

a code section for generating an absolute address format 
program by sequentially relocating instructions and 
reading said records of said second relative address 
format program one by one. 

22. A computer software product according to claim 21, 
wherein said computer readable medium is further stored 
thereon a code section for storing a header having an access 
permission condition set therein said second relative address 
format program, and when said access permission condition 
is satisfied, said instructions are sequentially relocated by 
reading said records of said second relative address format 
program one by one to generate said absolute address format 
program. 

23. A computer software product according to claim 21, 
wherein said computer readable medium is further stored 
thereon a code section for storing a header having attributes 
information set therein said second relative address format 
program. 

24. A computer software product according to claim 21, 
wherein said computer readable medium is further stored 
thereon: 

a code section for transforming a first relative address 
format program including an instruction string and 
relocation information into a second relative address 
format program including a set of records having a 
group of instructions including instruction relocation 
information and at least one instruction corresponding 
to said relocation information; and 

a code section for generating an absolute address format 
program by sequentially relocating instructions and 
reading said records of said second relative address 
format program one by one. 

25. A computer software product according to claim 21, 
wherein said computer readable medium is further stored 
thereon: 

a code section for storing said second relative address 
format program in at least one IC card, wherein said 
second relative address format program is loaded into 
memory to generate an absolute address format pro- 
gram by sequentially relocating instructions and read- 
ing said records of said second relative address format 
program one by one from said IC card. 

26. A computer software product including a computer 
readable medium, said computer readable medium having 
stored thereon: 
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a code section for transforming a first address format 
program including an instruction string and relocation 
information into a second relative address format pro- 
gram including a set of records each record having an 
instruction and instruction relocation information cor- 
responding to said instruction; and 

a code section for dividing said second relative address 
format program into a plurality of storage units, and 
storing said storage units into corresponding recording 
media. 

27. A computer software product according to claim 26, 
wherein said computer readable medium is further stored 
thereon: 

a code section for generating an absolute address program 
by sequentially relocating instructions and reading said 
records of said second relative address format program 
one by one in each storage unit. 

28. A computer software product according to claim 27, 
wherein said computer readable medium is further stored 
thereon: 

a code section for loading said absolute address format 
program, which has been generated, on a memory. 

29. A computer software product including a computer 
readable medium, said computer readable medium having 
stored thereon: 

a code section for transforming a first relative address 
format program including an instruction string and 
relocation information into a second relative address 
format program including a set of records each record 
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having an instruction and instruction relocation infor- 
mation corresponding to said instruction; and 
a code section for dividing said second relative address 
format program into a plurality of storage units, and 
s providing each storage unit with a header having set 
therein relocation information of each storage unit; and 
a code section for loading said storage units on a memory 
by reading said storage units in an optional sequence, 
and sequentially relocating instructions by reading said 
10 records of said second relative address format program 
one by one according to relocation information in the 
header of each storage unit that has been loaded. 
30. A computer software product including a computer 
readable medium, said computer readable medium having 
stored thereon: 

a code section for holding a sequentially transformable 
relative address format program including a set of 
records each record having an instruction and instruc- 
tion relocation information corresponding to said 
2Q instruction, and for having said relative address format 
program loaded into a computer; 
a code section for encrypting said relative address format 
program that has been loaded into said computer; and 
a code section for decrypting an encrypted relative 
2 5 address format program while sequentially relocating 
instructions by reading said records of said encrypted 
relative address format program one by one to thereby 
generate an absolute address format program. 

* * * * * 
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device type is discarded such that only the data which is 
associated with the determined device type is retained by the 
electronic device. Installation code is also incorporated into 
the download entity such that, once downloaded, the instal- 
lation code is executed by the electronic device to "unpack" 
and store the data associated with the device type from the 
download entity. 

13 Claims, 5 Drawing Sheets 
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APPARATUS AND METHOD FOR apparent upon reading and understanding the present 

DOWNLOADING DATA TO ELECTRONIC specification, the present invention discloses an apparatus 

DEVICE and method for downloading data in the form of a device 

type generic "download entity" (or data object) to an elec- 

BACKGROUND OF THE INVENTION 5 tronic device> By determining the device type of the elec- 

1. Field of the Invention tronic device and discarding any data in the download entity 

This invention relates in general to downloading data such whicD is not associated with the determined device type, 

as parameters and/or program code to an electronic device, only the data which is associated with the determined device 

and more particularly, to the provision of a generic "down- tv P e 15 retamed W lhe electronic device. The data in the 

load entity" (or data object) for use by an electronic device 10 download entity may include program code for execution on 

such as a disk drive, where only data from the download the electronic device and/or,.device parameters and other is 

entity which is associated with a determined device type for information that is utilized by the electronic device, 

the electronic device is retained by the electronic device. Preferred embodiments of the invention may also incor- 

2 Description of Related Art porate installation code into the download entity that, once 

As products are offered with a wider variety of 15 downloaded, is executed to "unpack" and store the data 

specifications, capacities and features, it becomes increas- associated with the device type from the download entity. By 

ingly difficult and costly to develop, produce, maintain and ^P™^ nation code in the download entity, 

support these products. For example, disk drives may be mstallalion functions may be omitted from the runtime code 

designed with varying capacities, data transfer rates, com- , n ui the device thereby minimizing .the amount of extraneous 

munication interfaces (e.g., IDE or SCSI), etc. Within a 20 0- c - , th u at 15 used onl y durm f puliation and not 

given product line, while a significant portion of the drive durm 6 runtirae > thal must remam resident 1D the device * 

mechanical and hardware components may be shared by Therefore, in accordance with the invention, there is 

different models, there may still be significant design provided a method for downloading data to an electronic 

variations, e.g., different numbers/sizes of disks and differ- device, the electronic device having a device type that is one 

ent numbers of heads. Similarly, while the basic functions of a plurality of device types. The method includes the steps 

and operations of the program code (which may include of receiving a download entity in the electronic device, the 

instructions, parameters, and other data) in a line of disk download entity including data associated with each device 

drives may be similar, the differences between models type; determining the device type of the electronic device; 

require differences in the program code for each model. arid discarding the data in the download entity not associated 

One approach for supporting the program code require- the d etermined device type such that only data asso- 

ments of multiple models or designs is to generate a single ciated ™ th the d etermined device type is retained by the 

program code implementation that, depending upon the electronic device. 

"device type" of the particular device in which the program In accordance with another aspect of the invention, an is 

code is installed, executes different routines and/or utilizes 35 electronic device is provided having a device type that is one 

different parameters to in effect customize the program code of a plurality of device types. The device includes memory 

for the particular device. However, maintaining duplicate means for storing operational data utilized during operation 

routines and parameter tables to support multiple device of the electronic device; receiver means for receiving a data 

types greatly increases space requirements. Moreover, the object externally from the electronic device, the data object 

additional processing required for runtime support of mul- 40 including data associated with a plurality of device types; 

tiple device types may adversely impact drive performance. and installation means for installing in the memory means 

Another approach for supporting multiple device types is 0Ill y data from the da ta object that is associated with the 

to generate separate "versions" of the program code for device tv P e of the electronic device, 

different device types, then load only one version into a According to a further aspect of the invention, a disk drive 

particular device. However, this requires knowledge at the 45 is provided, which includes a communications interface for 

downloading end (either by an operator or a downloading receiving a download entity, the download entity including 

computer) of the device type of the device to be loaded. data associated with a plurality of types of disk drives; a 

This requirement has drawbacks in many applications memory for storing operational data associated with the disk 

such as disk drive arrays where multiple disk drives are drive i and a controller, coupled to the communications 

linked together and controlled by an array controller, since 50 interface, the controller (1) determining a type for the disk 

different types of drives may be used together. Downloading drive > ( 2 ) retrieving from the download entity only the data 

to different drives in the array (e.g., to provide program code associated with the determined type for the disk drive, (3) 

updates) may be burdensome and time consuming, and it storing the data associated with the determined type for the 

may be difficult for a manufacturer to support multiple d isk drive in the memory, and (4) discarding any data in the 

device types. Moreover, automated downloading may be 55 download entity not associated with the determined type for 

particularly burdensome if it is difficult for the array con- me disk dnve. 

troller to detect the device type of each drive. In accordance with an additional aspect of the invention, 

Therefore, a substantial need has arisen for a manner of there is provided an apparatus, which includes an array of 

downloading data such as operating instructions, parameters direct access storage devices, each of which having a device 

and the like to electronic devices which supports multiple 60 type and a memory for storing operational data utilized in 

device types with minimum space requirements and without toe operation thereof; and an array controller or other control 

requiring knowledge of the device type by the downloading means (e.g., a processor used for field testing) controlling 

system. lh e arra y of direct access storage devices, the array control- 
ler providing a generic download entity to a plurality of the 

SUMMARY OF THE INVENTION 65 direct access storage devices to update the memories thereof, 

To overcome the limitations in the prior art described the generic download entity including operational data asso- 

above, and to overcome other limitations that will become ciated with a plurality of device types; wherein each of the 
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plurality of direct access S storage devices stores in its used in the alternative. As shown in FIG. 1, array controller 

memory only operational data from the download entity that 2 may also control other disk drive arrays, e.g., disk drives 

is associated with its respective device type and discards the 6 coupled through bus S. Moreover, instead of an array 

operational data not associated with its respective device controller, the drives in the disk drive array may be con- 

type. - 5 nected to and controlled by another host computer such as a 

According to another aspect of the invention, a download server computer system 4. Also, a host computer may be 

entity is provided for downloading to an electronic device uscd duri °g manufacturing to provide initial data and code 

having a device type that is one of a plurality of device types. 10 one or more °f lne drives. 

The download entity includes a block of data, the data block In general, it should be appreciated that while the pre- 
having portions associated with each of the plurality of 10 ferred electronic device is a disk drive, the principles of the 
device types; and an installation routine, executable by the invention may be applied to download data to practically 
electronic device, for retrieving only the portion of the data any electronic device. Moreover, while the source of the 
in the download entity that is associated with the device type downloaded data in the preferred embodiment is an array 
of the electronic device. controller or server, the source of the downloaded data may 
These and various other advantages and features of nov- 15 be any source of data, whether a computer, electronic device, 
elty which characterize the invention are pointed out with or program storage medium, which may connect and pro- 
particularity in the claims annexed hereto and form a part vide download data to an electronic device. Thus, the 
hereof. However, for a better understanding of the invention, preferred application shown herein is merely exemplary in 
its advantages, and the objects obtained by its use, reference nature. 

should be made to the drawings which form a further part 20 Disk drives 8, 9 and 10 are preferably 18 head 7200 RPM 
hereof, and to accompanying descriptive matter, in which disk drives (e.g., Scorpion disk drives available from Inter- 
there is illustrated and described specific examples of an national Business Machines Corporation). The mechanical 
apparatus in accordance with the invention. components of disk drive or magnetic storage system 10 are 

shown in greater detail in FIG. 2. The disk drive includes a 

BRIEF DESCRIPTION OF THE DRAWINGS 25 housing u and a housing cover 14 which, after assembly, is 

Referring now to the drawings in which like reference mounted within a frame 16. Mounted within the housing is 

numbers represent corresponding parts throughout: a s?™^ shaft 2Z Ratably attached to the spindle shaft 22 

™„ - . r> . • i Li 1 j ■ c c j are a number of magnetic storage disks 24. In FIG. 2, nine 

FIG. 1 is a functional block diagram of a preferred „ . f . 4 . . j, u ^ • A 

rn . . . , ... c,w«t „„tk iU» disks 24 are attached to the spindle shaft 22 in spaced apart 

apparatus having a disk drive array consistent with the 30 . ™ , ~, . 4 r . „ . ft , . f . 

■ • 1 c *u • relation. The disks 24 rotate on spindle shaft 22 which is 

principles of the invention; , . t , t , x T „ . . 

r r powered by a motor (not shown). Information is written on 

FIG. 2 is an exploded perspective view of the mechanical or rcad from me disks 24 by heads or magnetic transducers 

components in a disk drive from the disk drive array of FIG. (nm shown) which m SU p ported by sliders 2 6. Sliders 26 

1* are coupled to the suspensions or load springs 28. The load 

FIG. 3 is a functional block diagram of the controller 35 springs 28 are attached to separate arms 30 on an E block or 

components in a disk drive from the disk drive array of FIG. C omb 32, The E block or comb 32 is attached at one end of 

1, illustrating information flow between the components an actuator arm assembly 36. The actuator arm assembly 36 

during data downloading and installation; ^ rotatably attached within the housing 12 on an actuator 

FIG. 4 is a flowchart illustrating the program flow in the shaft 38. The rotary actuator assembly 36 moves the inle- 

disk drive of FIG. 3 during download of a download entity; 40 grated transducer/suspension assembly in an arcuate path 

and across the surface of the storage disk 24. However, the 

FIG. 5 is a flowchart illustrating the program flow of an invention is not meant to be limited to the particular disk 

installation routine downloaded with the download entity dr ive described herein, as any configuration of disk drive or 

illustrated in FIG. 3. direct access storage device (DASD) may be used consistent 

45 with the invention. 

DETAILED DESCRIPTION OF THE Returning to FIG. 1, the controller or functional compo- 
INVENTION nents of disk drive 10 are illustrated in greater detail. The 
In the following description of the exemplary primary disk drive control operations are shared by a pair of 
embodiment, reference is made to the accompanying draw- 50 controllers, interface controller 50 and servo controller 60. It 
ings which form a part hereof and in which is shown by way should be appreciated that, while controllers 50 and 60 are 
of illustration the specific embodiment in which the inven- preferably implemented with separate processors, the func- 
tion may be practiced. It is to be understood that other lions of each may be handled as different tasks in a single 
embodiments may be utilized as structural changes may be processor as well. 

made without departing from the scope of the present 55 Interface controller So coordinates the transfer of data 

invention. into and out of disk drive 10. Program code for the interface 

FIG. 1 illustrates an exemplary disk drive array apparatus controller is preferably stored in a non-volatile memory, e.g., 

1 showing one preferred application of the present inven- flash memory 54, or on a reserved area of the disk itself, and 

tion. Apparatus 1 preferably includes a plurality of disk work space for the controller is provided in random access 

drives, e.g., disk drives 8, 9 and 10, interconnected to an 60 memory (RAM) 52. Data that is transferred into and out of 

array controller 2 via a bus 3. Array controller 2 in the disk drive 10 is temporarily stored in a data buffer 42, and 

preferred embodiments operates as a host computer for a communications interface, e.g., bus interface 40, formats 

supplying the download entity to the disk drives in apparatus data for communicating with array controller 2 over bus 3. 

1- Servo controller 60 coordinates the movement of the 

Array controller 2 is preferably a RAMAC array control- 65 integrated transducer/suspension assembly for acquisition 

ler available from International Business Machines and storage of data onto the magnetic storage disks. ARAM 

Corporation, although other known array controllers may be 62 provides work space for the operation of the servo 
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controller, while program code therefor is stored either in 
RAM 62 or in a non -volatile memory (not shown). 

The functional components illustrated herein for disk 
drive 10 are representative of standard operating functions 
of many disk drives. Moreover, the hardware implementa- 5 
tions of these components are also representative of standard 
disk drive designs. Thus, the invention should not be limited 
to any particular hardware configuration. 

The preferred embodiments of the invention download 
operational data ("data") to disk drive 10 through a down- 10 
load entity, or data object, functionally represented with 
reference number 70 in FIG. 3. The data downloaded to disk 
drive 10 may include program code, e.g., to be executed by 
interface controller 50 and/or servo controller 60, and/or 
may include other data such as operational parameters 15 
specific to disk drive 10. The types of parameters which may 
be utilized by disk drive 10 include dimensional parameters 
(e.g., number of heads, number of servo cells per revolution, 
etc.), physical parameters (e.g., arm length, moment of 
inertia of arm, stroke length, capable force factors, rotation 20 
speed, etc.), electrical parameters, servo system constants 
(utilized in servo algorithms), filter coefficients, and system 
flags (e.g., to enable/disable functions), among others. 

Download of data to disk drive 10 may occur, for example 
during the manufacture of the drive, or may occur to update 25 
the program code and/or operating parameters to provide 
new functionality, correct any "bugs" in the program code, 
or otherwise modify the operation of disk drive 10. 

Download entity 70 preferably includes a data block 3Q 
containing all of the program code and/or parameter data to 
accommodate multiple device types or models for disk drive 
10. All of this information is preferably stored in a type table 
74. In addition, installation code 72 is included in the 
download entity to install the proper components in disk 35 
drive 10 based upon its particular device type. 

Consistent with the invention, the installation code uti- 
lizes the type table to retrieve from the download entity only 
program code and/or parameter data associated with the 
particular device type of disk drive 10 The associated data ^ 
retrieved from the type table is preferably stored is ulti- 
mately in flash memory 54. A flash (or data) image block 76 
is reserved in the download entity of the preferred embodi- 
ment for building the associated data to be stored in flash 
memory 54. Block 76 may initially include default values 45 
and routines so that only device type specific modifications 
may need to be retrieved from the download entity. Also, as 
discussed below, the current contents of the flash memory 
may also be copied to the image block to provide a basis for 
updating the flash memory with the data from the download 50 
entity. 

To illustrate the operation of the preferred embodiments 
of the invention, the update of servo parameters for drive 10 
is explained in conjunction with FIGS. 3-5. As shown in 
FIG. 3, the servo parameters are maintained in a parameter/ 55 
code (or data) block 78 in flash memory 54. A copy of block 
78 is also kept in RAM 62 for use by servo controller 60, as 
well as in RAM 52 of interface controller 50 to permit 
controller 50 to monitor calibration routines in servo con- 
troller 60. 60 

FIG. 4 illustrates a download routine 100 executed by 
interface controller 50 in response to a download command 
datablock (CDB) sent over bus 3 by array controller 2 or 
another host computer in apparatus 1. 

The download command is initially processed by inter- 65 
face controller 50 in the same manner as any other incoming 
datablock received by disk drive 10 over bus 3, in a manner 
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generally understood in the art. Once the download com- 
mand is received, however, a short bootstrap routine 100, 
initially resident in the flash memory, is executed to initiate 
processing of the download entity. Primary handling of the 
download entity installation, however, is preferably reserved 
for the installation code that is downloaded within the entity. 

By including many of the installation processes within the 
download entity, the amount of permanent resident code in 
flash memory 54 that is dedicated to download processing is 
minimized. It will be appreciated that flash memory is 
comparatively expensive, so minimization of extraneous 
code is often desirable. Moreover, by including the instal- 
lation code with the download entity, customized installation 
code may be developed to handle the download and selected 
by device type. However, it should be appreciated that all of 
the installation code may be permanently maintained in flash 
memory 54 and omitted from the download entity in the 
alternative. 

Turning to FIG. 4, execution of routine 100 begins in 
block 102 by receiving download entity 70 from bus 3 into 
data buffer 42. As discussed above, the download entity 
includes installation code 72, type table 74, and flash image 
76. 

Next, in block 104, installation code 72 is copied into 
RAM 52 of interface controller 50. Then, in block 106, the 
copy of the installation code in RAM 52 is provided with 
pointers to any resident utility routines in flash memory 54 
that may be utilized by installation code 72. The use of these 
shared routines may reduce the size of installation code 72 
since functions and tools that are resident in flash memory 
54 need not be duplicated in installation code 72, Also in 
block 104, it is preferable to provide a device type indication 
to the installation code so that the installation code recog- 
nizes the device type of the disk drive, for use as will be 
discussed in greater detail below. 

Blocks 104 and 106 prepare the installation code for 
execution by interface controller 50. Consequently, upon 
execution of these blocks, the installation code is called in 
block 108 to pass control to the new code for data retrieval 
from download entity 70. 

A preferred installation code or routine 110 is illustrated 
in FIG. 5. Execution of routine 110 begins in block HI, 
where the current contents of the flash memory are copied 
into the buffer flash image 76 to provide a basis from which 
updates to the flash memory may be made. It should be 
appreciated that only a small portion of the flash memory 
may need to be updated, and therefore it may be desirable to 
provide only updated data in the download entity, rather than 
having to build the entire flash memory from scratch. On the 
other hand, if the entire flash memory is provided with the 
download entity, block 111 may not be required. 

Next, in block 112 device type table 74 is accessed to 
determine which components to retrieve from download 
entity 70. Then, in block 114, the image of the data is built 
in block 76 by retrieving the necessary components from the 
download entity and updating the relevant portions of the 
flash image. Once the new image is constructed, block 116 
then writes the image into flash memory 54. 

It should be appreciated that it may not be necessary to 
build a complete image of the flash in the data buffer before 
copying the image to the flash memory as disclosed herein. 
Rather, it may be possible to update the flash memory by 
writing directly thereto. However, some flash memories 
require that the entire memory space be cleared and rewrit- 
ten in its entirety, and thus, it is preferred herein to first build 
the flash image in the data buffer and then write the updated 
image into the flash memory. 
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The "device type" of disk drive 10 preferably represents 
a particular model or design indicator. In the area of disk 
drives, this may represent models that are distinguished 
based upon memory capacity, data transfer rate, interface 
type (e.g., IDE, SCSI, etc.), number of disks and heads, and 
disk size, among others. For other electronic devices, other 
device types may be defined, which would vary significantly 
based upon the device. As one example, base and enhanced 
models may be distinguished so that only authorized func- 
tions and features are stored in a device. This enables the 
same hardware platform to be used for multiple models, 
multiple product lines or even for different products alto- 
gether (generically "electronic products"), with the control- 
ling software tailored for particular device types. As another 
example, for a personal digital assistant (PDA), different 
device types may be distinguished based upon the language 
of the user, so that the messages displayed by the PDA will 
be in the user's native language. Innumerable other varia- 
tions are possible within the scope of the invention. 

In the preferred embodiments, the device type table is 
accessed via a device type indicator that is provided to the 
installation code by interface controller 50, preferably from 
a device type maintained in the flash memory, stored in 
another non -volatile device (e.g., DIP switches), or on the 
disk itself. Moreover, this device type may be rewritten by 
the installation code into the flash memory during the 
download process if necessary. The use of a specific device 
type indicator minimizes the complexity of the installation 
code. However, it is also possible for the installation code to 
determine the device type in other manners, e.g., by testing 
one or more device characteristics known to vary among 
different device types. For example, the number of heads in 
each device type may vary, whereby the installation code 
may detect the device type by energizing all heads and 
detecting the number of heads that respond. Other manners 
of detecting the device type internal to the disk drive may be 
used in the alternative. 

Also in the preferred embodiments, device type table 74 
provides separate tables for each parameter with an index 
table or map (indexed by device type) that generates indexes 
or pointers so that block 114 may pull parameter values from 
the parameter tables and thereby build flash image block 76. 
In the alternative, table 74 may provide complete parameter 
sets indexed by device type, whereby the operation of block 
114 is primarily to copy a complete parameter set to block 
76. The data in type table 74 may also be compressed and/or 
encoded, and then unpacked by the installation code. Other 
manners of storing data in the download entity for subse- 
quent retrieval by the installation code may also be used in 
the alternative. 

Additionally, retrieval of data from type table 74 may 
depend on other factors as well as device type. For example, 
the previous state or history of the drive may be a factor used 
in the selection of data from type table 74. 

Returning to FIG. 5, once the flash image has been copied 
to flash memory 54, block 118 is executed to initiate a 
power-up reset on the drive. By initiating the power-up reset, 
the drive is reset to normal operating conditions. Data buffer 
42 and RAMs 52 and 62 are cleared, thereby discarding the 
download entity and any data therein not associated with the 
device type of disk drive 10. The installation code is also 
preferably discarded in this process. 

Block 118 may also include the step of saving a "key" or 
other indicator, preferably in one of RAMs 52, 62 or data 
buffer 42, or in a register, to indicate that the power-up reset 
is a result of a download. The power-up routine would then 
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be required to check the appropriate location for the key 
during power-up and prior to clearing out the memories and 
registers in the system. Consequently, the power-up routine 
for drive 10 may include a step 120 for sending a completed 

5 response to the host computer initiating the download. Drive 
state information may also be saved by block 118 so that, 
upon power-up, the current drive conditions (or "drive 
state"), e.g., spin up status, etc., may be restored. 
The preferred embodiments provide substantial benefits 

10 over conventional downloading methods. In particular, 
although multiple device types are supported by a single 
download entity, unused data is discarded, thereby reducing 
the size of the downloaded data. Moreover, specific runtime 
processing to handle multiple device types is eliminated. 
Given the expense of non-volatile (flash) memories, any 

15 manner of reducing memory space requirements is particu- 
larly beneficial. 

Moreover, in applications such as disk drive arrays, the 
preferred embodiments further provide the benefit of sub- 
stantially simplified and faster automated update of multiple 

20 disk drives. In particular, a single download entity may be 
downloaded by an array controller or other host computer to 
multiple disk drives, optionally simultaneously via a 
broadcast-type command. Each disk drive, based upon its 
recognized device type, then takes only the information 

25 associated with its device type from the download entity and 
discards the remaining information. As an additional benefit, 
only a single download entity need be supported, with the 
installation knowledge encoded within the download entity 
itself. Accordingly, no knowledge of device type is required 

30 for the operator or the host computer. Other advantages and 
benefits should be apparent to one of ordinary skill in the art. 

It will be appreciated that the various data, program code, 
parameters, etc. in the download entity are resident at 
different times on one or more "program storage devices." 

35 Generically, the term "program storage device" may include 
any device or apparatus capable of storing information such 
as data or program code either in a volatile or non-volatile 
manner, including memory devices such as RAMS, ROMS, 
EPROMs. processor and cache memories, flash memories, 

40 etc.; as well as fixed or removable mass storage media such 
as magnetic disks (fixed or removable), CD-ROMs, mag- 
netic tape, etc. 
The foregoing description of the exemplary embodiment 

45 of the invention has been presented for the purposes of 
illustration and description. It is not intended to be exhaus- 
tive or to limit the invention to the precise form disclosed. 
Many modifications and variations are possible in light of 
the above teaching. It is intended that the scope of the 

5Q invention be limited not with this detailed description, but 
rather by the claims appended hereto. 
What is claimed is: 

1. A method executed by an electronic device wherein the 
electronic device downloads data, the electronic device 
55 having a device type that is one of a plurality of device types, 
the method comprising the steps of: 
(a) receiving a download entity in a data buffer of the 
electronic device, the download entity including data in 
a device type table associated with each device type; 
60 ( D ) providing to the download entity an indication of at 
least one device type associated with the electronic 
device; 

(c) building a data image in a data image block of the 
download entity from data retrieved from the device 

65 type table; 

(d) writing the data image block from the data buffer to 
the electronic device to provide the electronic device 
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with data only associated with indicated device types 
associated with the electronic device, the writing fur- 
ther comprising 

(1) retrieving from the download entity an installation 
routine, wherein the installation routine is provided 
with pointers to utilities resident on the electronic 
device for executing the installation routine; and 

(2) executing the installation routine by the electronic 
device to store into non-volatile memory of the 
electronic device only the data associated with the 
indicated device types; - 

wherein retrieving and executing are performed at 
least in part by a download processing routine 
resident in the electronic device; and 
(e) initiating a reset to clear the data buffer. 

2. The method of claim 1, wherein the data associated 
with the indicated device types are stored in non-volatile 
memory in the electronic device. 

3. Trie method of claim 1, wherein the data in the 
download entity comprises program code for execution by 
the electronic device. 

4. The method of claim 1, wherein the data in the 
download entity comprises device parameters characterizing 
the electronic device. 

5. The method of claim 1, wherein the download process- 
ing routine is called in response to a download command 
transmitted from a host computer. 

6. The method of claim 1, further comprising before 
building the data image in the data image block, copying the 
current contents of the non-volatile storage in the electronic 
device to the data image block. 
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7. The method of claim 1, wherein the providing step 
including the step of testing one or more operating charac- 
teristics of the electronic device, wherein the tested operat- 
ing characteristics vary between different device types. 
5 8. The method of claim 1, wherein the electronic device 
is a disk drive, the disk drive including the data buffer for 
receiving the download entity, and a first controller, coupled 
to the data buffer and utilizing the data associated with the 
indicated device types, 

9. The method of claim 8, wherein the disk drive further 
includes the non-volatile memory, coupled to the first 
controller, for storing the data associated with the indicated 
device types. 

10. The method of claim 8, wherein the data in the 
download entity includes servo parameters characterizing 

15 the disk drive, and wherein the disk drive further includes a 
second controller, coupled to the first controller, the second 
controller having a random access memory for storing the 
servo parameters associated with the indicated device types. 

11. The method of claim 10, wherein the first and second 
20 controllers comprise the same processor. 

12. The method of claim 8, wherein the disk drive is one 
of an array of disk drives controlled by an array controller, 
the method further comprising the step of transmitting the 
download entity to a plurality of disk drives in the array; 

25 whereby each of the plurality of disk drives retains only the 
data in the download entity associated with its determined 
device type. 

13. The method of claim 1, wherein the device type table 
is indexed by device type. 

30 

* * * * * 
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